

System call conversion for year 2038 - signa11
http://lwn.net/SubscriberLink/643234/6e05b14dcd966636/

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

[http://www.openbsd.org/55.html](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.

~~~
justincormack
NetBSD also switched over in 6.0 back in 2012.

~~~
ivoras
And FreeBSD apparently started in 2001:
[http://mm.icann.org/pipermail/tz/2004-June/012487.html](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.

~~~
abadabalinux4u
While Linux certainly reinvents the wheel in some cases and NIHism exists
everywhere, the syscall interface of an operating system is not the place
where one can just lift BSD code and drop it in and expect it to work. This
work needs to be done carefully in a Linux-specific way. The "NIH" approach is
sort of a requirement.

~~~
duaneb
Linux seems to have a policy of avoiding breaking changes. Nice for
maintaining software, but it's not the best quality kernel as a result.

------
kagamine
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
Time to use RISC-V processors. They can be 128-bit.

~~~
kagamine
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).

~~~
infogulch
If you a single type that counts the number of Plank Time units (10^-44 s)
from the big bang until the heat death of the universe, how many bits would
you need?

If the heat death of the universe is 10^100 years, that's 6*10^150 plank times
[1]. log_2(that) ~ 500 bits. So you'd probably go with 512 bits for a
maximally-precise time type that will never need to be updated for either size
or precision.

[1]:
[http://www.wolframalpha.com/input/?i=convert+10%5E100+years%...](http://www.wolframalpha.com/input/?i=convert+10%5E100+years%2Buniverse+age+to+Planck+times)

~~~
repsilat
Two points:

\- Quantization of time is _not_ a part any widely accepted physical theory,
and the evidence we have so far is consistent with time being continuous.
Timekeeping with Planck time units would be "nice" (well, "overkill" and
"impossible" are two good words to come to mind as well), but there's no
reason in theory that you can't go finer.

\- When your time is this fine, you also need to talk in very specific ways
about reference frames. Time passes at different rates at different altitudes,
and relative velocities also screw with you. Where's your reference clock? In
some inter-galactic space, stationary relative to the CMB?

~~~
infogulch
To be fair, this is more an exercise in taking "future-proofing" to a logical
extreme than something practical (or even possible).

With that context I (arbitrarily) chose plank time to be the smallest
possibly-ever usable (maybe not practical) time scale for timekeeping.

That's a good point about location. If we're going for extremes, we should put
it in one of the especially large spaces between galaxy clusters:
supervoids[0]! If there were a clock made at plank time frequency, I wonder
how much of an effect structures would have on it at interstellar,
intergalactic, and void space distances. At this accuracy (and these
distances) I imagine the _clock 's own gravity_ would be a major source of
time dilation.

Perhaps the best setup would be an extremely small (think the size of a virus)
clock with a small support station that provides energy to it and reads ticks
back, kept a few hundred thousand light-years away to avoid gravitational
influence.

Another thing. 10^100 years is a _long_ time. So long that if the time from
the big bang to the heat death of the universe were one second long, the
universe isn't even 1 plank time old yet. 10^100 years is so long it starts
making sense to talk about the half-lives of elements that are considered
perfectly stable. To make _any_ clock that is designed to operate continuously
for that long would be a crazy undertaking even for an interstellar
civilization.

[0]:
[https://en.wikipedia.org/wiki/Void_(astronomy)](https://en.wikipedia.org/wiki/Void_\(astronomy\))

------
kokey
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
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
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.

------
andrewd18
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
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.

------
bryanlarsen
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
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
My phone's web-browser only supports up to SSLv3 :(

