Hi,
For Lua32, as well as for Linux32, this 2038 problem of os.time is really quite nerving.
As date and time in my software is used only "sometimes" / not heavily, I would like to use somehow a practical solution to get rid of this problem. (and not for the next 50 years, but better for the next at least 400 years or so... please do not start making bad jokes about this "solution" approach ..:).).
In my own "practical approach" I would now not count the number of seconds, but the number of 8 seconds - this is perfectly fine for any "file safe time" and also "message event times" of my system - for users who want more exact timings, I anyway present some msec-Delay timers.
To test, how much effort it would be for me to change Lua32 to this other timescale, I commented '#include <time.h>' in loslib.c and defined the basic types 'time_t' and 'struct tm' manually (just copied them from time.h to loslib.h.
If I compile then loslib.c, my ARMCC Compiler will throw 8 warnings for the following missing functions: 'clock', 'time', 'gmtime', 'localtime', 'strftime', 'mktime', 'difftime'.
I assume all these functions with exception of strftime I can manage quite easily re-program in some hours ... the tricky thing is a bit how to get the day info from the timer value ... but there are quite nice and cute and short algorithms for this task in the Internet available... .
strftime depends only on the 'struct tm' - so I can just continue to use the library strftime. (As I change the time_t only, of course I only need to re-write the functions which use time_t, and strftime fortunately does NOT...).
Do you think this approach makes sense to give it a try? Or did some others possibly tried something like this by themselves already? Or would you predict to me some further bad surprises, as soon as I have fixed loslib.c like this? (up to now I do not have experience in touching the Lua c sourcecode ... this would be my first try, so I am happy concerning "any warnings"... ).
-
