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: Tue, 11 Mar 2025 23:21:40 +0100
Organization: A noiseless patient Spider
Lines: 120
Message-ID: <vqqd1l$26qs8$1@dont-email.me>
References: <vqpkf9$1sbsa$1@dont-email.me> <vqpoi3$226ih$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 11 Mar 2025 23:21:41 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a3feb33278c234e7d6bd4e3c3d6843cd";
	logging-data="2321288"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18VKhYa1jhnE75YXtAj8Rli/jQar+YB5Uk="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:vKXmcxZjEtOC91RW3zC1wMTqocg=
Content-Language: it
In-Reply-To: <vqpoi3$226ih$1@dont-email.me>
Bytes: 6376

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.

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.


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


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

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

> 
> 
> David
> 
> 
>> In this build system the type time_t is defined as long, so 32 bits.
>>
>> I'm using time_t mainly to show it on a display for the user (as a 
>> broken down time) and tag with a timestamp some events (that the user 
>> will see as broken down time).
>>
>> The time can be received by Internet or by the user, if the device is 
>> not connected. In both cases, time_t is finally used.
>>
>> As you know, my system will show the Y2038 issue. I don't know if some 
>> of my devices will be active in 2038, anyway I'd like to fix this 
>> potential issue now.
>>
>> One possibility is to use a modern toolchain[1] that most probably 
>> uses a new version of newlib that manages 64 bits time_t. However I 
>> think I should address several warnings and other problems after 
>> upgrading the toolchain.
>>
>> Another possibility is to rewrite my own my_mktime(), my_localtime() 
>> and so on that accepts and returns my_time_t variables, defined as 64 
>> bits. However I'm not capable in writing such functions. Do you have 
>> some implementations? I don't need full functional time functions, for 
>> example the timezone can be fixed at build time, I don't need to set 
>> it at runtime.
>>
>> Any suggestions?
>>
>>
>> [1] https://developer.arm.com/-/media/Files/downloads/gnu/14.2.rel1/ 
>> binrel/arm-gnu-toolchain-14.2.rel1-mingw-w64-i686-arm-none-eabi.zip
>