On Saturday, 10 July 2021 at 01:11:28 UTC, Steven Schveighoffer
wrote:
You can get better than hnsecs resolution with
`core.time.MonoTime`, which can support whatever the OS
supports.
However, `Duration` and `SysTime` are stored in hnsecs for a
very specific reason -- range. Simply put, if you have a 64-bit
integer, and you picked nanoseconds as the unit, you can store
only 585 years of range. 10 ns gives you 5850 years, and 100 ns
gives you 58k years. That should be good enough for all but the
most esoteric calculations (given that a `Duration` is signed,
this gives a range of roughly -29k years to 29k years).
Note also that hnsecs is the base unit for Windows high
precision clocks, though their epoch is year 1600 instead of
year 0.
Nice summary. hnsecs is a little weird but defensible given the
range argument.
Down the road we might add a nanosecond timeline abstraction
based on TAI with zero set to 1972 (when UTC was aligned with TAI
IIUC). Range issues could be addressed by animating the long
dormant cent. Any precision issues could be handled with fixed
point pairs.
Doubles across the same timeline would work for casual
applications.
