LWN: Comments on "System call conversion for year 2038"

System call conversion for year 2038

neilbrown — Fri, 15 May 2015 03:56:56 +0000

> NFSv3 has a similar problem,

Similar, but not the same.
NFSv3 time stamps are unsigned, so they reach until 2106, but don't go back before 1970.

See RFC1813 definition of nfstime3. Linux server and client get this right (but silently truncate any timestamps out side that range).

System call conversion for year 2038

eternaleye — Wed, 13 May 2015 23:01:31 +0000

They are exactly that - but when POSIX defines things in terms of the fuzzy types, even the sensible people who use stdint can't escape.

(of course, for FFI there's libc::c_int and so on, but that's just it: for FFI.)

System call conversion for year 2038

rleigh — Wed, 13 May 2015 21:08:09 +0000

Are the Rust types not exactly the same as the long established C99 <stdint.h> or C++11 <cstdint>? I haven't used the "fuzzy" types much in over a decade!

System call conversion for year 2038

eternaleye — Wed, 13 May 2015 20:37:05 +0000

Oh, ick. 34 bits total of wastage? Sure, struct alignment would mean the same wastage in arrays, but still...

This is really reinforcing my preference for Rust's [ui]{64,32,16,8} integer types over C's (unsigned) {long long,long,int,short,char} fuzzily-sized ones :/

(and Rust then has usize, defined as "capable of holding a pointer", for the cases where that's relevant)

System call conversion for year 2038

joib — Wed, 13 May 2015 17:56:47 +0000

Struct timespec is specced in posix to have a time_t value for seconds since the epoch, and a long value for fractional nanoseconds. Both are 64 bits on 64-bit Linux targets.

System call conversion for year 2038

eternaleye — Wed, 13 May 2015 03:10:57 +0000

Well, the 12-byte struct is what everyone's been working with on 64-bit for quite a while now as I understand it - 64-bit seconds, 32-bit nanoseconds (or microseconds, for the struct timeval antiques). On 32-bit it might even be _less_ painful, as on some 32-bit architectures (x86?) u64 has 4-byte alignment IIRC, rather than 8-byte.

System call conversion for year 2038

eternaleye — Wed, 13 May 2015 03:08:54 +0000

That would seem to militate in favor of separate time formats for "point time" (timespec) and "interval time" (u64 ns) - as has occurred in more modern date/time libraries, such as Joda Time.

Furthermore, at that point "now" could be defined in an offset-ish way - use point time for "when we booted" and interval time for "...and how long has it been since then?"

But that'd be an even more drastic API change, and thus deeply unlikely.

System call conversion for year 2038

flussence — Tue, 12 May 2015 16:44:27 +0000

I'm not so sure there's much of a need to represent intervals close to Planck time within the kernel. Couldn't we compromise on 64 bit seconds and 32 bit subseconds, or would a 12-byte struct be too awkward to work with here?

System call conversion for year 2038

arnd — Tue, 12 May 2015 09:14:18 +0000

Well, as was discussed in the email thread, anything that deals with inode time stamps has to use a 64-bit seconds value, and that is good enough for all practical uses. Using sub-nanosecond values for the fractional seconds would add very noticeable overhead with little benefit.

For interfaces that deal with timeouts (e.g. clock_nanosleep()), or current time (e.g. clock_gettime()), using unsigned 64-bit nanoseconds gives us until 2554, over 500 years before we have to come up with something else. If we can gain a noticeable performance improvement using the nanosecond based interface until then, it should be worth the effort.

System call conversion for year 2038

Karellen — Sun, 10 May 2015 12:45:10 +0000

The trouble with a 64-bit signed nanosecond representation of time is that 30 bits are needed for nanosecond precision, meaning only 2 bits are added to the number of representable seconds. While this does mean quadrupling the current range of ±68 years to ±272 years, designing our clocks to "only" be able to represent times between the years 1698 and 2242 seems a little short-sighted.

If we doubled the size just one more time, with 64-bit seconds (±10^12 years) and 64-bit sub-second-precision (10^-18s), we could handle all almost any time anyone would wish to theoretically manipulate.

Transistor density, and therefore memory sizes, have increased by a factor on the order of a million since the early '70s when time_t was first invented. Surely we can afford to more than just double the size of our timestamps?

Time, Clock, and Calendar Programming In C

jnareb — Thu, 07 May 2015 15:26:57 +0000

On related note, there is nice article by ESR titled "Time, Clock, and Calendar Programming In C" http://www.catb.org/esr/time-programming/

System call conversion for year 2038

arnd — Thu, 07 May 2015 13:14:15 +0000

That's up to the libc implementation. Glibc developers have said in the past that they would do it like this, while I expect most others will require a complete rebuild of all user space.

System call conversion for year 2038

meuh — Thu, 07 May 2015 12:05:13 +0000

Are we going to see preprocessor #define _TIME_BITS 64 just like we have -D_FILE_OFFSET_BITS=64 ?

2038 in the mainstream news

eru — Thu, 07 May 2015 05:16:00 +0000

Year 2038 and other such roll-overs are getting even the attention of BBC: http://www.bbc.com/future/story/20150505-the-numbers-that-lead-to-disaster

System call conversion for year 2038

nevets — Thu, 07 May 2015 03:01:33 +0000

> (Incidentally, the "kill this" comment was added by Andrew Morton in 2007; nobody has killed it yet.)

I think I peed my pants!