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)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux