System call conversion for year 2038

http://lwn.net/SubscriberLink/643234/6e05b14dcd966636/

by signa11 • 11 years ago

76 36 11 years ago

kagamine3• 11 years ago

So what this means, according to the comment by user Arnd at lws, is that even though I built a 64 bit time machine I still cannot travel further into the future than 2242 or further back than 1698? My life's work, ruined.

higherpurpose• 11 years ago

Time to use RISC-V processors. They can be 128-bit.

kagamine3• 11 years ago

What if I want to go even farther? Can someone on HN tell me if 128 bits is enough to get me from the dawn of the universe to the end of time (at work so I can't do it myself for another 4 hours).

espadrine• 11 years ago

Don't they mention 2554 for unsigned 64-bit?

Also, wouldn't the kernel keep the original time? Time conversion could be performed in userland, with big integers.

Dylan16807• 11 years ago

No, that's the option they didn't chose.

You won't be able to use ext4 though.

Edit: Unless you already...

kokey• 11 years ago

What this made me think of is how many 32 bit, Linux-based, microcontrollers and IoT devices are out there and in the making. Many of these might actually still be relied on 23 years from now.

jamescun• 11 years ago

It is worrying. A possible work around for the remaining 32-bit systems would be a patch to switch to using an unsigned 32-bit integer for time storage, however this will only work for systems that don't need to deal with dates before 1970, but pushes the problem back to 2106.

Someone• 11 years ago

You also will have to be absolutely sure that those systems will never run code that compares timestamps using a signed 32-bit comparison. That means vetting all the code, not only the OS.

Even for devices where all the code is in ROM, that can be difficult. Source may be lacking, or there may be binary blobs bought from companies that do not exist anymore.

wongarsu2• 11 years ago

For embedded systems, PIC24 microcontrollers are still popular. Those are 16 bit microcontrollers typically used without operating system. The one I last wrote production software on will display incorrect dates in 2036, and there are no libraries available to mitigate that.

At least in my case the date weren't mission crucial, but I expect a lot of factory hardware to behave weirdly starting on either 7th February 2036 or 19. January 2038.

Siecje• 11 years ago

Why those two dates?

mrweasel• 11 years ago

Very likely it's already to late for some systems. I wouldn't be surprised if some of the systems already in production will last until sometime after 2038.

Expecting short upgrade cycles is normal in software/computing, but for manufacturing 30 to 50 years doesn't seem unrealistic. 23 years is a very short time, even if we stay in the field of computing, mainframes are getting close to 23 year life cycles.

pilif• 11 years ago

Or, worse, actual binary protocols that use 32bit integers to represent time values.

bryanlarsen• 11 years ago

Fixing the kernel now gives applications >20 years to get fixed up. There will still be a huge scramble in the dying months of 2037...

hsivonen• 11 years ago

Today a commented on a bug report from someone who still hasn't migrated to a UTF-8 locale. And when POODLE happened, there were still servers on SSLv3. So, yeah. :-(

aidenn0• 11 years ago

My phone's web-browser only supports up to SSLv3 :(

ghshephard• 11 years ago

OpenBSD made some good progress back in 5.5 (May, 2014)

http://www.openbsd.org/55.html

  o time_t is now 64 bits on all platforms.
  o From OpenBSD 5.5 onwards, OpenBSD is year 2038 ready
  o The entire source tree (kernel, libraries, and userland 
    programs) has been carefully 
    and comprehensively audited to support 64-bit time_t.
  o Userland programs that were changed include arp(8),
    bgpd(8), calendar(8), cron(8), find(1), 
    fsck_ffs(8), ifconfig(8), ksh(1), ld(1), ld.so(1),
    netstat(1), pfctl(8), ping(8), rtadvd(8), ssh(1),
    tar(1), tmux(1), top(1), and many others, including
    games!
  o Removed time_t from network, on-disk, and database 
    formats.
  o Removed as many (time_t) casts as possible.
  o Format strings were converted to use %lld and (long
    long) casts.
  o Uses of timeval were converted to timespec where 
     possible.
  o Parts of the system that could not use 64-bit 
     time_t were converted to use unsigned 32-bit instead,
     so they are good till the year 2106.
  o Numerous ports throughout the ports tree received 
    time_t fixes.

justincormack2• 11 years ago

NetBSD also switched over in 6.0 back in 2012.

ivoras• 11 years ago

And FreeBSD apparently started in 2001: http://mm.icann.org/pipermail/tz/2004-June/012487.html

While it did advance the state of the art in many things, Linux really clings to reinventing the wheel in obvious cases. NIH FTW.

andrewd18• 11 years ago

Please don't post LWN subscriber-only content until it's released to the public. I value LWN and would like to see its subscriber numbers increase, not have its content poached by content aggregators.

corbet• 11 years ago

I appreciate your concern, but we don't mind if an occasional subscriber link is posted this way. It gets us a lot of readers we might not otherwise reach and, with luck, leads to more subscribers going forward.

System call conversion for year 2038

Related Stories