Year 2038 preparations in 3.17

Posted Aug 9, 2014 4:01 UTC (Sat) by jstultz (subscriber, #212)
In reply to: Year 2038 preparations in 3.17 by josh
Parent article: Year 2038 preparations in 3.17

First of all, for now the timespec64 is a kernel-internal only structure, so its not exactly enshrined at this point.

Secondly, timespecs are desired because quite often folks really just want seconds, not nanoseconds, so we internally in the kernel have to keep both ktime_t and timespec style structures for performance reasons.

Finally, depending on how we do the userspace interface changes, we may want to try to allow applications to possibly just be re-compiled to gain 2038 support, instead of requiring developers to rework the application to use new types. So preserving the timespec style will be important here. (Granted, this won't solve all the places applications store time in non-time_t related structures, but likely will go a long way.)

Year 2038 preparations in 3.17

Posted Aug 14, 2014 19:29 UTC (Thu) by spitzak (guest, #4593) [Link] (1 responses)

Why not count in some power of .5 rather than seconds or nanoseconds. I.e. use fixed-point. That makes arithmetic easy, and getting the number of seconds easy.

I sure don't like the idea that the timestruct is going to be 12 bytes rather than a power of 2.

A fixed-point system would be better, 1 sign bit + 33 integer bits + 30 bits fraction. That is in units of 1/1073741824 second, allowing all nanoseconds to have unique values. And if will be good until the year 2242. And it would use 8 bytes, the same size as the current structure.

Year 2038 preparations in 3.17

Posted Aug 14, 2014 19:49 UTC (Thu) by jwakely (subscriber, #60262) [Link]

NTP has a 64-bit fixed-point timestamp, see http://tools.ietf.org/html/rfc5905#section-6

> The 64-bit timestamp format is used in packet headers and other places with limited word size. It includes a 32-bit unsigned seconds field spanning 136 years and a 32-bit fraction field resolving 232 picoseconds.