Groups | Search | Server Info | Login | Register
Groups > comp.arch.embedded > #32362
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: 32 bits time_t and Y2038 issue |
| Date | 2025-03-14 13:27 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <vr17ak$rtjs$2@dont-email.me> (permalink) |
| References | (5 earlier) <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> |
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
>>> 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 :
>
> 1. Use the standard functions from your toolchain. You've ruled out
> using those with your current toolchain, and ruled out changing the
> toolchain, so this won't do.
Chaning the toolchain is a possibile solution. I have to check yet.
> 2. Use an implementation from other library sources online. You've
> ruled those out as too complicated.
In the past I sometimes lurked in the newlib code and it seems too
complicated for me. I will search for other simple implementations of
localtime()/mktime().
> 3. Write your own functions. Yes, that involves a certain amount of
> work, testing and risk. That's your job.
>
> Am I missing anything?
I don't think.
>>>>> 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.)
>>
>> Of course, the quartz has an accuracy that changes with life,
>> temperature an so on. However the real accuracy doesn't allow the time
>> drifting so much the user needs to reset the time.
>>
>
> A standard cheap nominal 32.768 kHz is +/- 20 ppm. That's 1.7 seconds
> per day - assuming everything in the hardware is good. Often that's
> good enough, but sometimes it is not. Only you can answer that one.
It's enough.
>>>> - 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.
>>
>> Maybe Windows is not able, but I'm reading Linux is. It saves the time
>> as UTC on the hw RTC and shows it to the user as localtime, of course
>> applying dst and timezone rules from a database of rules.
>
> Yes, Linux has had NTP, timezones and daylight savings since its early
> days (as have other *nix OS's).
>
>>
>> So, as long as the timezone/dst info for my timezone is correct, I
>> think Linux could manage dst changes automatically without user activity.
>>
>> My approach is identical to what Linux does.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar
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