Groups | Search | Server Info | Login | Register

Groups > comp.arch.embedded > #32357

Re: 32 bits time_t and Y2038 issue

Show all headers | View raw

On 12/03/2025 18:13, pozz wrote:
> Il 12/03/2025 17:39, David Brown ha scritto:
>> 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. 
> 
> If I got your point, adding one second to struct mytm isn't reduced to a 
> ++ on one of its member. I should write something similar to this:
> 
> if (mytm.tm_sec < 59) {
>    mytm.tm_sec += 1;
> } else {
>    mytm.tm_sec = 0;
>    if (mytm.tm_min < 59) {
>      mytm.tm_min += 1;
>    } else {
>      mytm.tm_min = 0;
>      if (mytm.tm_hour < 23) {
>        mytm.tm_hour += 1;
>      } else {
>        mytm.tm_hour = 0;
>        if (mytm.tm_mday < days_in_month(mytm.tm_mon, mytm.tm_year)) {
>          mytm.tm_mday += 1;
>        } else {
>          mytm.tm_mday = 1;
>          if (mytm.tm_mon < 12) {
>            mytm.tm_mon += 1;
>          } else {
>            mytm.tm_mon = 0;
>            mytm.tm_year += 1;
>          }
>        }
>      }
>    }
> }
> 

Yes, that's about it.

> However taking into account dst is much more complex. The rule is the 
> last sunday of March and last sunday of October (if I'm not wrong).

No, it is not complex.  Figure out the rule for your country (I'm sure 
Wikipedia well tell you if you are not sure) and then apply it.  It's 
just a comparison to catch the right time and date, and then you add or 
subtract an extra hour.

> 
> All can be coded manually from the scratch, but there are standard 
> functions just to avoid reinventing the wheel.

You've just written the code!  You have maybe 10-15 more lines to add to 
handle daylight saving.

> 
> Tomorrow I could install my device in another country in the world and 
> it could be easy to change the timezone with standard function.

How many countries are you targeting?  Europe all uses the same system.

<https://en.wikipedia.org/wiki/Daylight_saving_time_by_country>

> 
>> Adding or subtracting an hour on occasion is also simple.
> 
> Yes, but the problem is *when*. You need to know the rules and you need 
> to implement them. localtime() just works.
> 

You are getting ridiculous.  This is not rocket science.

Besides, any fixed system is at risk from changes - and countries have 
in the past and will in the future change their systems for daylight 
saving.  (Many have at least vague plans of scraping it.)  So if a 
simple fixed system is not good enough for you, use the other method I 
suggested - handle it by regular checks from a server that you will need 
anyway for keeping an accurate time, or let the user fix it for 
unconnected systems.

> 
>> 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. 
> 
> What do you mean with "next daylight savings change"? I'm using NTP 
> (specifically SNTP from a public server) and I'm able to retrive the 
> current UTC time in seconds from Unix epoch.
> 
> I just take this value and overwrite my internal counter.
> 
> In other application, I retrive the current time from incoming SMS. In 
> this case I have a local broken down time.
> 
> 
>> 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 
> 
> Drifts? By using a 32.768kHz quartz to generate a 1 Hz clock that 
> increases the internal counter avoid any drifts.

There is no such thing as a 32.768 kHz crystal - there are only 
approximate crystals.  If you don't update often enough from an accurate 
time source, you will have drift.  (How much drift you have, and what 
effect it has, is another matter.)

> 
> - 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.
> 
> I think you can take into account dst even if the device is not connected.
> 

You certainly can.  But then you have to have a fixed algorithm known in 
advance.

> I bet Windows is able to show the correct time (with dst changes) even 
> if the PC is not connected.
> 

I bet it can't, in cases where the date system for the daylight savings 
time has changed or been removed.  Other than that, it will just use a 
table of date systems such as on the Wikipedia page.  Or perhaps MS 
simply redefined what they think other people should use.

Older Windows needed manual changes for the date and time, even when it 
was connected - their support for NTP was late.

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

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 16:22 +0100
  Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-11 17:32 +0100
    Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-11 23:21 +0100
      Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 10:33 +0100
        Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 16:48 +0100
          Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 17:39 +0100
            Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 18:13 +0100
              Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 19:18 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-13 09:57 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-13 16:51 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 13:27 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-14 14:20 +0100
    Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-12 08:44 +0100
      Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-12 11:14 +0100
      Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-14 01:48 +0000
        Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-14 08:36 +0100
    Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 16:30 +0000
      Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-15 17:02 +0000
        Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-15 23:26 +0000
      Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 09:21 +0100
        Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 11:34 +0100
          Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-18 17:31 +0100
            Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:29 +0100
              Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:20 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 13:54 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 20:53 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 11:19 +0100
                Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:35 +0000
          Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:28 +0000
            Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-18 20:43 +0100
              Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-18 20:58 +0000
                Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-18 23:31 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 11:24 +0100
                Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 14:27 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 17:33 +0100
                Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-19 19:08 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 21:14 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:48 +0000
                Re: 32 bits time_t and Y2038 issue Grant Edwards <invalid@invalid.invalid> - 2025-03-21 13:27 +0000
                Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-19 22:09 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-20 09:26 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:40 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-21 09:23 +0000
                Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-21 22:38 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-19 08:24 +0100
              Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-21 14:04 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-21 16:45 +0100
                Re: 32 bits time_t and Y2038 issue pozz <pozzugno@gmail.com> - 2025-03-21 22:51 +0100
                Re: 32 bits time_t and Y2038 issue Hans-Bernhard Bröker <HBBroeker@gmail.com> - 2025-03-22 00:00 +0100
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 14:29 +0100
                Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-22 14:46 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 17:57 +0100
                Re: 32 bits time_t and Y2038 issue antispam@fricas.org (Waldek Hebisch) - 2025-03-22 15:57 +0000
                Re: 32 bits time_t and Y2038 issue David Brown <david.brown@hesbynett.no> - 2025-03-22 18:02 +0100
        Re: 32 bits time_t and Y2038 issue Michael Schwingen <news-1513678000@discworld.dascon.de> - 2025-03-18 18:44 +0000

csiph-web