LWN: Comments on "A draft glibc year-2038 design document"

A draft glibc year-2038 design document

toyotabedzrock — Mon, 17 Apr 2017 07:53:09 +0000

Accounting software used by the government often need for make predictions for 10+ years out. So you might have less than half the time to fix it if it isn't already messing with social security calculations.

A draft glibc year-2038 design document

jag — Sat, 25 Feb 2017 14:25:38 +0000

Per https://www.spinics.net/lists/y2038/msg01959.html "microseconds" was replaced with "nanoseconds" in revision 118.

You can find the most recent version here: https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

As for the tv_nsec in timeval, the text above the code snippet mentions that tv_usec is mandated by POSIX, so to me it seems like a copy&paste error for the code snippet which then was perpetuated from there into the text below it. I've let the author know.

I don't get the impression that the author misunderstands the subject matter, but rather that it's a case of editing fatigue / blindness. It's precisely why you ask others to read your drafts.

A draft glibc year-2038 design document

peda — Fri, 24 Feb 2017 18:44:26 +0000

I'm not going to bother with that since the chance of anyone actually doing as described in the document is nil. It's just mildly amusing that those who supposedly knows this best (or some of them anyway) also make mistakes with timeval/timespec.

A draft glibc year-2038 design document

corbet — Fri, 24 Feb 2017 17:23:56 +0000

If you feel you have found something incorrect in the document, the best thing to do would be to respond in the original thread. The problem has a much higher chance of being fixed that way.

A draft glibc year-2038 design document

peda — Fri, 24 Feb 2017 17:12:16 +0000

Heh, the draft thinks that the tv_nsec field in struct timespec is microseconds and proposes that the Y2038-compatible struct timeval should also have a tv_nsec field (instead of the mandated tv_usec field). Someone didn't proofread (or is seriously confused).

But then again, having both struct timeval and struct timespec was inevitably going to lead to crap. I just thought folks doing time in glibc was on top of that and knew that shit like the above happens just about every time you are not super careful with those two structs...

A draft glibc year-2038 design document

abelloni — Fri, 24 Feb 2017 10:25:45 +0000

Yeah but it will not hit any platform smart enough to know that it is not 1972 anymore. Maybe I'm too optimistic but I would hope that this includes all current platforms.

A draft glibc year-2038 design document

ghane — Thu, 23 Feb 2017 05:49:03 +0000

On a different note, NTP will break in 2036, so we *may* have precise kernel timestamps in the years following, with no way to synchronise between systems.

The Apocalypse is closer than you think :-)

A draft glibc year-2038 design document

jhoblitt — Wed, 22 Feb 2017 19:50:33 +0000

My head blew up reading the design doc -- which looks like a great example of how to plan a refactoring of a complex code base. Seriously, these folks are unsung heros...

Time in perspective

pr1268 — Wed, 22 Feb 2017 17:31:11 +0000

me@mylappy:~$ echo "$(date +%s -d "01 Jan 2000 00:00:01 -0000")/2^31" | bc -l
.44083446310833096504
me@mylappy:~$ echo "$(date +%s)/2^31" | bc -l
.69280358171090483665

We're almost as close to the Y2038 apocalypse as the Y2K "problem" was to us now. Gee... where does the time go? :-\

P.S. Kudos to the glibc team for staying focused on this.