Pondering 2038 - a suggestion for an improved time_t

Posted Aug 18, 2013 22:26 UTC (Sun) by Cyberax (✭ supporter ✭, #52523)
In reply to: Pondering 2038 - a suggestion for an improved time_t by sdalley
Parent article: Pondering 2038

You can only store 2 seconds in 32-bit signed field with nanosecond resolution. So the most significant part would have to store seconds, and we only have 32 bits for that.

So I vote for 64 bit whole second counter and 32 bit nanosecond counter.

Pondering 2038 - a suggestion for an improved time_t

Posted Aug 18, 2013 23:58 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Actually, let's go with 64 bits for seconds and 64 bits for attoseconds (why not go for the overkill?).

Pondering 2038 - a suggestion for an improved time_t

Posted Aug 19, 2013 9:10 UTC (Mon) by sdalley (subscriber, #18550) [Link] (1 responses)

But leap seconds would still be broken.

And atomicity becomes (even) more of an issue once you exceed 64 bits. Tick precision down to 100ns avoids this.

When you care about the last nanosecond, you usually don't care at all about the epoch. Why have an excessively large size in order to accommodate both? For nanoseconds, we can just stick to using clock_gettime(CLOCK_MONOTONIC,).

Pondering 2038 - a suggestion for an improved time_t

Posted Aug 19, 2013 11:31 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

No, for leap seconds we'd just have nsec/attosec part to go up to 2 seconds instead of one. So it works.

And if you don't want extra precision then you can simply ignore it. Or we can do the same trick one more time: use 64 bit for seconds, 32 bits for nanoseconds and 32 bits for attoseconds.