Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Wed, 12 Mar 2025 16:48:39 +0100
Organization: A noiseless patient Spider
Lines: 179
Message-ID: <vqsacn$2g8c7$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 12 Mar 2025 16:48:39 +0100 (CET)
Injection-Info: dont-email.me; posting-host="41a992101a24e7f83d269d554023444b";
	logging-data="2630023"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+TGvjipHDHf5NeyE4GzcroOsiQLz9An/U="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:eDoaOQyLHbkynhkOpWYnjeCrHUU=
In-Reply-To: <vqrkd5$2hnm3$1@dont-email.me>
Content-Language: it
Bytes: 9530

Il 12/03/2025 10:33, David Brown ha scritto:
> On 11/03/2025 23:21, pozz wrote:
>> Il 11/03/2025 17:32, David Brown ha scritto:
>>> On 11/03/2025 16:22, pozz wrote:
>>>> I have an embedded project that is compiled in Atmel Studio 7.0. The 
>>>> target is and ARM MCU, so the toolchain is arm-gnu-toolchain. The 
>>>> installed toolchain version is 6.3.1.508. newlib version is 2.5.0.
>>>>
>>>
>>> I /seriously/ dislike Microchip's way of handling toolchains.  They 
>>> work with old, outdated versions, rename and rebrand them and their 
>>> documentation to make it look like they wrote them themselves, then 
>>> add license checks and software locks so that optimisation is 
>>> disabled unless you pay them vast amounts of money for the software 
>>> other people wrote and gave away freely.  To my knowledge, they do 
>>> not break the letter of the license for GCC and other tools and 
>>> libraries, but they most certainly break the spirit of the licenses 
>>> in every way imaginable.
>>
>> Maybe you are thinking about Microchip IDE named MPLAB X or something 
>> similar. I read something about disabled optimizations in the free 
>> version of the toolchain.
>>
> 
> I believe it applies to all of Microchip's toolchains - and that now 
> includes those for the Atmel devices it acquired.
> 
>> However I'm using *Atmel Studio* IDE, that is an old IDE distributed 
>> by Atmel, before the Microchip purchase. The documentation speaks 
>> about some Atmel customization of ARM gcc toolchain, but it clearly 
>> specified the toolchain is an arm gcc.
> 
> OK.
> 
>>
>>
>>> Prior to being bought by Microchip, Atmel was bad - but not as bad.
>>
>> Why do you think Atmel was bad? I think they had good products.
> 
> It is not the products that I am talking about.  I've always like the 
> AVR architecture (though it could have been massively better with a few 
> small changes).  Though I haven't used their ARM devices myself, I have 
> heard nice things about them.  I am talking about the toolchains.
> 
> They had a very mixed attitude to open source software.  

I suspect because of Arduino, that is open source and started with 
ATmega328.


> For a long 
> time, they dismissed GCC completely, and gave no help or information for 
> other parts of the ecosystem (debuggers, programmers, etc.).  Eventually 
> they realised that there was a substantial customer base who did not 
> want to pay huge prices for IAR toolchains, or preferred open-source 
> toolchains for other reasons, and they made various half-hearted efforts 
> to support GCC for the AVR.  Basically, they did enough to be able to 
> have a working setup that they could provide it for free, but not enough 
> to make it efficient.  I think they spent more money on rebranding GCC 
> for the AVR and ARM than they did on technically improving them.  People 
> looking for AVR GCC toolchains were left with no idea what version of 
> GCC they can get from Atmel, or how those builds compare with mainline 
> GCC versions, what devices they support, or how the various required 
> extensions are handled.  Their ARM toolchains were a bit more standard, 
> and a bit less obfuscated in their branding and versioning.
> 
> So not as bad as Microchip, but still far from good.

I didn't follow the history of AVR MCUs and the available toolchains. I 
only used the AVR toolchain installed by Atmel Studio (I think by 
Atmel), but I know there's at leat winavr project. I don't know if there 
are real differeces between them.


>>> So if for some reason I have no choice but to use a device from Atmel 
>>> / Microchip, I do so using tools from elsewhere.
>>>
>>> As a general rule, the gcc-based toolchains from ARM are the industry 
>>> standard, and are used as the base by most ARM microcontroller 
>>> suppliers.  Some include additional library options, others provide 
>>> the package as-is.  For anything other than a quick demo, my 
>>> preferred setup is using makefiles for the build along with an ARM 
>>> gcc toolchain.  That way I can always build my software, from any 
>>> system, and archive the toolchain.  (One day, I will also try using 
>>> clang with these packages, but I haven't done so yet.)
>>
>> Yes, you're right, but now it's too late to change the toolchain.
>>
>>
>>> Any reasonably modern ARM gcc toolchain will have 64-bit time_t.  I 
>>> never like changing toolchains on an existing project, but you might 
>>> make an exception here.
>>
>> I will check.
>>
>>
>>> However, writing functions to support time conversions is not 
>>> difficult.   The trick is not to start at 01.01.1970, but start at a 
>>> convenient date as early as you will need to handle - 01.01.2025 
>>> would seem a logical point.  Use <https://www.unixtimestamp.com/> to 
>>> get the time_t constant for the start of your epoch.
>>>
>>> To turn the current time_t value into a human-readable time and date, 
>>> first take the current time_t and subtract the epoch start.  Divide 
>>> by 365 * 24 * 60 * 60 to get the additional years.  Divide the 
>>> leftovers by 24 * 60 * 60 to get the additional days.  Use a table of 
>>> days in the months to figure out the month.  Leap year handling is 
>>> left as an exercise for the reader (hint - 2100, 2200 and 2300 are 
>>> not leap years, while 2400 is).  Use the website I linked to check 
>>> your results.
>>
>> If I had to rewrite my own functions, I could define time64_t as 
>> uint64_t, keeping the Unix epoch as my epoch.
>>
>> Regarding implementation, I don't know if it so simple. mktime() fix 
>> the members of struct tm passed as an argument (and this is useful to 
>> calculate the day of the week). Moreover I don't only need the 
>> conversion from time64_t to struct tm, but viceversa too.
>>
> 
> Day of week calculations are peanuts - divide the seconds count by the 
> number of seconds in a day, add a constant value for whatever day 
> 01.01.1970 was, and reduce modulo 7.

Yes, you should be right.


> Most of the effort for converting a struct tm into a time_t is checking 
> that the values make sense.
> 
> 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.


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