lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

In 2038, more precisely 2038-01-19 04:14:07, 2147483648 seconds since 1970-01-01 0:00:00 will have elapsed. This is 2^31 seconds, and only a problem if this time is a signed integer, which may work in some systems
(On Linux, gives reasonable results for negative values)

But that may get dropped in benefit of gaining some time.
I guess it will happen that instead for looking for +/-68 years around 1970-01-01, the definition will be changed to up to +136 years since 1970-01-01 (and nothing before that). I.e. we will have another 68 years until the 32 bit counter will spill over.

In that time span we (or our children, grand children, ... ) should be able to fix that issue. Maybe once for all* time with a 64 bit time...


* OK not *all* time but 584 586 860 415 years  IS enough for the estimated life time of this universe.

Am 10.08.21 um 19:59 schrieb Flyer31 Test:
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"... ).