4 ms·
Timestamps are 64bit nanoseconds As far as I can tell, this will overflow in just 11 years – 2028-06-15 09:33:27.3709551615 UTC Why would this go into a new s
by jdmnd 9y ago
Timestamps are 64bit nanoseconds
As far as I can tell, this will overflow in just 11 years – 2028-06-15 09:33:27.3709551615 UTC
Why would this go into a new standard? Is there a practical use for such a high level of granularity?
edit: off by a factor of 10 in my calculation...
It's actually
2554-07-21 23:34:33.709551615 UTC
- DuskStar 9y ago2^64 nanoseconds is ~584 years, though.
- raldi 9y agoBy my math, we're fine for almost 600 years: http://wolframalpha.com/input/?i=2%5E64+nanoseconds+from+now&x=0&y=0 http://wolframalpha.com/input/?i=2%5E64+nanoseconds+from+now...
- cimnine 9y agoBut that should be 'from 1.1.1970', i.e. from the unix epoch. Still far out, though.
- twoodfin 9y ago2^64 nanoseconds is > 580 years. Even cutting it in half for signed values is still likely 10X the expected lifetime of this particular iteration of APFS. The granularity is probably useful for establishing an ordering (even somewhat arbitrarily) for highly concurrent file system operations, and thus potentially skipping a bunch of expensive synchronization.
- lowercaseman 9y agoFound this: https://github.com/jbenet/nanotime https://github.com/jbenet/nanotime. No idea if related in any way or used for APFS but it was interesting enough for a quick read. This one is MIT licensed. A little more searching I found a variant but it's done with big-endian so it's much different.
- achivetta 9y ago64-bit nanosecond values are actually pretty common on Darwin already. See e.g. clock_gettime_nsec_np(3).