Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch.embedded
Subject: Re: 32 bits time_t and Y2038 issue
Date: Thu, 13 Mar 2025 16:51:23 +0100
Organization: A noiseless patient Spider
Lines: 263
Message-ID: <vquuts$3et7q$1@dont-email.me>
References: <vqpkf9$1sbsa$1@dont-email.me> <vqpoi3$226ih$1@dont-email.me>
 <vqqd1l$26qs8$1@dont-email.me> <vqrkd5$2hnm3$1@dont-email.me>
 <vqsacn$2g8c7$1@dont-email.me> <vqsdcv$2mp5u$1@dont-email.me>
 <vqsfc3$2g8c7$2@dont-email.me> <vqsj69$2o1s0$1@dont-email.me>
 <vqu6lo$34o8d$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 13 Mar 2025 16:51:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f42f249bde5fd152e2d97dfd52aade64";
	logging-data="3634426"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19llJp/GVx68HhrPhryxhRZjMlMCKiCqII="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:2Hc/KW7d25fxPFp4yIcmvS9666U=
Content-Language: en-GB
In-Reply-To: <vqu6lo$34o8d$1@dont-email.me>
Bytes: 12388

On 13/03/2025 09:57, pozz wrote:
> Il 12/03/2025 19:18, David Brown ha scritto:
>> 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.
> 
> Ok, but I don't understand why you prefer to write your own code (yes, 
> you're an exper programmer, but you can introduce some bugs, you have to 
> write  some tests), while there are standard functions that make the job 
> for you.
> 

I prefer to use a newer version of the toolchain that does not have such 
problems :-)

I am quite happy to re-use known good standard functions.  There is no 
need to reinvent the wheel if you already have one conveniently 
available.  But you don't have standard functions conveniently available 
here - the ones from your toolchain are not up to the task, and you are 
not happy with the other sources you have found for the standard functions.

So once you have eliminated the possibility of using pre-written 
standard functions, you then need to re-evaluate what you actually need. 
  And that is much less than the standard functions provide.  So write 
your own versions to do what you need to do - no more, no less.


> I could rewrite memcpy, strcat, strcmp, they aren't rocket science, but 
> why? IMHO there is no sense.

I have re-written such functionality a number of times - because 
sometimes I can do a better job for the task in hand than the standard 
functions.  For example, strncpy() is downright silly - it is 
inefficient (it copies more than it needs to), and potentially unsafe as 
it doesn't necessarily copy the terminator.  memcpy() can be inefficient 
in cases where the programmer knows more about the alignment or size 
than the compiler can prove.  And so on.

> 
> In my case standard functions aren't good (because of Y2038 issue) and 
> rewriting them can be a valid solution. But if I had a 64 bits time_t, I 
> would live with standard functions very well.
> 

And if pigs could fly, you could probably teach them to program too. 
You can't use the standard functions, so you have to look elsewhere. 
Writing them yourself is a simple and convenient solution.

> 
>> 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.
> 
> My users like the automatic dst changes on my connected and unconnected 
> devices. The risk of a future changes in the dst rules doesn't seem to 
> me a good reason to remove that feature.
> 

Okay, so you have to put it in.

As I see it, the options are :

========== REMAINDER OF ARTICLE TRUNCATED ==========