[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: lua32: Any easy fix for 2038 problem of os.time?
- From: Oliver Kroth <oliver.kroth@...>
- Date: Tue, 10 Aug 2021 20:28:20 +0200
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, os.date 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
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
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"... ).