Thanks - that is indeed a problem I hadn’t thought of…
It may be better to abstract the functionality to an interface, for which the user can define conforming implementations. I experimented with the opposite problem (saving bits by changing the epoch) in
https://github.com/tpapp/FlexDates.jl
and it would be nice to have all these approaches work together.
For the record:
I have published the first version of AstroTime.jl.
We had a discussion about the accuracy and resolution here: https://github.com/JuliaAstro/AstroTime.jl/issues/28
In theory we should be able to achieve an accuracy of 55 attoseconds for a range of 10x the age of the universe (I have not tested these extremes though because most date-based algorithms become meaningless there). Shifting an epoch with a subsecond offset close to machine precision by a million years works though (see here)
pkg> add TimesDates
using TimesDates, Dates
tm = TimeDate(now()) + Microsecond(12) + Nanosecond(345)
2019-02-13T04:15:48.250012345
string(tm)
"2019-02-13T04:15:48.250012345"
q.v. GitHub - JeffreySarnoff/TimesDates.jl: Nanosecond resolution for Time and Date, TimeZones