[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: lua32: Any easy fix for 2038 problem of os.time?
- From: Flyer31 Test <flyer31@...>
- Date: Wed, 18 Aug 2021 19:52:49 +0200
Hi Sam,
thank you - but this you have to do only if time_t is defined signed
int. You have to look how in time.h the typedef time_t looks like.
In Keil ARM_CC time_t is defined by:
typedef unsigned int time_t;
If time_t is defined like this, then all should be fine until 2108 "by
compiler default".
Just if you want to "drill this up" to later times, then in 32bit
systems it definitely will need some thinking how to program the
localtime function while avoiding to load 64bit arithmetics only for
this single application ...
... but lazy as I am I think I will accept for now that 80 years is a
quite fine lifetime for my electronics... .
(I also do not really understand what you mean by "time_64bit" in your
code ... this typically would imply that in your C compiler you have
already some sort of 64bit math included ... in this case then of
course localtime can be easily extended to > 32 bits ... my
application uses Cortex M4 32bit CPU, and I want to somehow use "not
too large" ROM code, therefore I want to avoid any 64bit arithmetics
in my code - I also would not like to use ...ULL numbers in my code
due to this reason... further localtime from 32bit time_t will run
only some 10 usec or so ... 64bit would run quite a bit longer
(typically factor 100 longer I am frightened, as my 32bit CPU has no
intrinsice 64bit division command...)).
On Wed, Aug 18, 2021 at 5:02 PM Sam Trenholme <lua@samiam.org> wrote:
>
>
> > You don't need any more than 32 bits until about 2100.
> > All you need is to look at time_t as an usigned 32bit value.
>
>
> The way I handle this is with code like this:
>
> if(time_32bit < -1) {
> time_64bit = time_32bit + 4294967296ULL;
> } else {
> time_64bit = time_32bit;
> }
>
> This gives us a good time until 2100 or so (2108, actually). Converting
> time in to a normal year/month/day would require a big huge tine
> conversion library, but this gives us a usable UNIX timestamp for the
> next 80-88 years on 32-bit systems.
>
> -- Sam