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

[Flyer31 Test <flyer31@...>]

Hi Oliver,
thank you for fast answer.

Of course with 64bit this will be fixed "infinitely", so on Win64 or
Linux64 all fine.

But I am interested in Lua32 for Single-Chip-Microcontroller solution
for really small systems (e. g. IoT applications, ONE Silicon chip
with ROM / RAM all on this chip / no external HDD/SDD or other things
like in PC or smart phone or so...). For such Microcontrollers, e. g.
STM32 with ARM Cortex M4/M7..., the current memory limit is in the
range of 1MegaByte... this still is VERY far away from he 2Giga Limit
of 32bits... so it would make definitely no sense to enlarge such
controllers to 64bit. 32bit really will "continue to live" on such
controllers still for VERY long time I would dare to predict. (you
have to see that 64 bit became on PCs only a pressing issues, when the
RAM sizes started to scratch at the 2Giga limit for the "mass market",
this was around year 2000....).

So 64bit is NO solution for me - I really LOVE these cute small 32bit
controllers. And including 64bit arithmetics or "int numbers" just for
some "date computing issues" which are used quite seldom by my users,
would be no good approach, as I see it... . Further adding 64bit
Integers to Lua32 also would be somehow a "quite crazily complicated
task" I think - also very tricky to explain to some "standard Lua
user" - a Lua user somehow is used to the fact, that numbers are
something "fairly easy" without having to think of bits and bytes like
in C.

On Tue, Aug 10, 2021 at 8:28 PM Oliver Kroth <oliver.kroth@nec-i.de> wrote:
>
> 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"... ).
> > -
> >