[go: up one dir, main page]
|
|
Log in / Subscribe / Register

Pondering 2038 - a suggestion for an improved time_t

Pondering 2038 - a suggestion for an improved time_t

Posted Aug 19, 2013 9:10 UTC (Mon) by sdalley (subscriber, #18550)
In reply to: Pondering 2038 - a suggestion for an improved time_t by Cyberax
Parent article: Pondering 2038

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,).

to post comments

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.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds