Re: lua32: Any easy fix for 2038 problem of os.time?

[Oliver Kroth <oliver.kroth@...>]

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...

Regards,

Oliver
__
* 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:
> 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"... ).
> -