Reply to post: Re: 2038

Y2K quick-fix crick? 1920s come roaring back after mystery blip at UK's vehicle licensing agency

Paul Crawford Silver badge

Re: 2038

What seems to be missing here is the original topic - trying to fix 2038 in existing 32-bit Linux programs.

The only proper fix (i.e. works as before with signed time_t and works beyond 2038) is to go 64-bit for time_t at least (other integers can be still be 32-bit if you are targeting 32-bit MCUs etc). But that needs a re-compile of the OS and the applications (Perl interpreter in your case). And beyond that it also requires anything that maps time_t in to some structure to accommodate that. Fine for internal memory structures that are re-defined on compile to use 64-bit time_t but no use for code that has time in files, shared memory, etc, so a re-compile for 64-bit is not going to work that easily unless the program already has a debugged 64-bit version.

My point was to fix / fudge existing compiled 32-bit code the least-worst option is to make the Linux system libraries treat time_t as unsigned so it runs 1970 to 2106. Yes it breaks pre-1970 date conversion (but that was never defined as working anyway) but there are no better alternatives. Changing the epoch (even dynamically via environment variable per program, etc) will also risk breaking code that has pre-compiled time-points based on 1970, etc. If your machine is running day-to-day, and not working for very old dates, going unsigned for the internal conversion will work well enough. But there will always be something that breaks if you change it, is that any worse than everything breaking post-2038?

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER

Biting the hand that feeds IT © 1998–2020