Changing signed time_t (MAX 03:14:07 on Tuesday, 19 January 2038) to an unsigned 32-bit integer (MAX, 06:28:15 on Sunday, 7 February 2106)

Changing signed time_t (MAX 03:14:07 on Tuesday, 19 January 2038) to an unsigned 32-bit integer (MAX, 06:28:15 on Sunday, 7 February 2106)

[Steger, Matthew]

See https://en.wikipedia.org/wiki/Year_2038_problem

I do Farebox Software and we have *NO NEED* for negative 32-bit time (prior to 1970).
                Just need to compare DATE on a Smart Card to today's DATE to see if it is "expired"
And of course have "show time" functions to show as DD/MM/YYYY HH:MM:SS

Has there been any consideration to adding a compiler/linker option like "-UnsignedTime" to convert "time_t" to UNSIGNED 32-bit INT so we (and I would presume a *LOT* of other embedded users) will have the option to extend  32-bit time past 2038 to 2106 with just a Compiler Option (of course losing times before 1970)???
                All TIME conversion functions would have to take this into account (including Printf Time Formats)

Otherwise I (we) will have to make our own Utime_t type and use that instead of time_t and write equivalents of all the time/printf functions to use this (now unsigned int value) correctly (i.e. do everything on our own!).

Thanks!

P.S. we usually "date" our Smart Cards to Expire 10 years in the future...that is now 2031...so we are getting *CLOSE* to the 2038 limit...

Matthew B. Steger | Sr. Software Engineer
T +1.847.871.1177 | M +1.630.254.2243

Genfare | 800 Arthur Ave | Elk Grove Village IL 60007

Genfare.com<https://www.genfare.com/> | LinkedIn<https://www.linkedin.com/company/genfare> | Customer Care<https://www.genfare.com/customer-care/>

The information contained in this electronic mail transmission is intended by SPX Corporation for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected.

Re: Changing signed time_t (MAX 03:14:07 on Tuesday, 19 January 2038) to an unsigned 32-bit integer (MAX, 06:28:15 on Sunday, 7 February 2106)

[Segher Boessenkool]

Hi!

On Thu, Feb 25, 2021 at 10:13:04PM +0000, Steger, Matthew wrote:
> Has there been any consideration to adding a compiler/linker option like "-UnsignedTime" to convert "time_t" to UNSIGNED 32-bit INT so we (and I would presume a *LOT* of other embedded users) will have the option to extend  32-bit time past 2038 to 2106 with just a Compiler Option (of course losing times before 1970)???

time_t is defined via #include <time.h>, and that belongs to your C
library, not to GCC.

For many systems time_t is a 64-bit time, and most of the world will go
there for 32-bit systems as well, naming that new type __time64_t for
example, as described for glibc at
  <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>


You can ask whoever provides your <time.h> what their plans for y2038
are.  Sorry we cannot help you.  Good luck,


Segher