Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: pozz <pozzugno@gmail.com>
Newsgroups: comp.arch.embedded
Subject: Re: 32 bits time_t and Y2038 issue
Date: Fri, 14 Mar 2025 13:27:01 +0100
Organization: A noiseless patient Spider
Lines: 283
Message-ID: <vr17ak$rtjs$2@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> <vquuts$3et7q$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 14 Mar 2025 13:27:01 +0100 (CET)
Injection-Info: dont-email.me; posting-host="e5e0fe066aa49a10d2e00a72828e1842";
	logging-data="915068"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/hjgBlhj9QGtQCXdrlS35myt0p0kbJ0zI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:XAtMuyV+6t2NAD6qXd7Ys7XAt+c=
In-Reply-To: <vquuts$3et7q$1@dont-email.me>
Content-Language: it
Bytes: 13355

Il 13/03/2025 16:51, David Brown ha scritto:
> 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 :-)

Sure, but the project is old. I will check if using a newer toolchain is 
a feasible solution for this project.


> 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 agree with you. I thought you were suggesting to use custom made 
functions in any case, because my approach that uses time_t counter 
(seconds from epoch) and localtime()/mktime() isn't good.


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

Yes, if your functios are better than standard functions, it's the way 
to go for me too.


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

Yes.

>>> 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 
========== REMAINDER OF ARTICLE TRUNCATED ==========