Re: 32 bits time_t and Y2038 issue

On 12/03/2025 16:48, pozz wrote:

Il 12/03/2025 10:33, David Brown ha scritto:

For all of this, the big question is /why/ you are doing it.  What are you doing with your times?  Where are you getting them?  Are you actually doing this in a sensible way because they suit your application, or are you just using these types and structures because they are part of the standard C library - which is not good enough for your needs here?

 When the user wants to set the current date and time, I fill a struct tm with user values. Next I call mktime() to calculate time_t that is been incrementing every second.
 When I need to show the current date and time to the user, I call localtime() to convert time_t in struct tm. And I have day of the week too.
 Consider that mktime() and localtime() take into account timezone, that is important for me. In Italy we have daylight savings time with not so simple rules. Standard time functions work well with timezones.
 

Maybe you are going about it all the wrong way.  If you need to be able to display and set the current time and date, and to be able to conveniently measure time differences for alarms, repetitive tasks, etc., then you probably don't need any correlation between your monotonic seconds counter and your time/date tracker.  All you need to do is add one second to each, every second.  I don't know the details of your application (obviously), but often no conversion is needed either way.

 I'm talking about *wall* clock only. Internally I have a time_t variable that is incremented every second. But I need to show it to the user and I can't show the seconds from the epoch.
 

The sane way to do this - the way it has been done for decades on small embedded systems - is to track both a human-legible date/time structure (ignore standard struct tm - make your own) /and/ to track a monotonic seconds counter (or milliseconds counter, or minutes counter - whatever you need).  Increment both of them every second.  Both operations are very simple - far easier than any conversions.  Adding or subtracting an hour on occasion is also simple.
If your system is connected to the internet, then occasionally pick up the current wall-clock time (and unix epoch, if you like) from a server, along with the time of the next daylight savings change.  If it is not connected, then the user is going to have to make adjustments to the time and date occasionally anyway, as there is always drift - they can do the daylight saving change at the same time as they change their analogue clocks, their cooker clock, and everything else that is not connected.

 

Or you can get the sources for a modern version of newlib, and pull the routines from there.

>
It's a very complex code. time functions are written for whatever timezone is set at runtime (TZ env variable), so their complexity are higher.
>

>
So find a simpler standard C library implementation.  Try the avrlibc, for example.
>
But I have no doubt at all that you can make all this yourself easily enough.

 I think timezone rules are not so simple to implement.
 

You don't need them.  That makes them simple.