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: 32 bits time_t and Y2038 issue
Date: Tue, 11 Mar 2025 16:22:17 +0100
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <vqpkf9$1sbsa$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 11 Mar 2025 16:22:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a3feb33278c234e7d6bd4e3c3d6843cd";
	logging-data="1978250"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/QFigEJz2eJnuydkryfI64hnYCRswj0xE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ulxsCbeIIwfIL2LjYQ6UHp5FXSo=
Content-Language: it
Bytes: 2427

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.

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