Closed alvaroc1 closed 3 years ago
Before fixing this to nanoseconds could we consider the convenience of representing historical dates. With nanoseconds, we can fit in 280 years either side of the epoch into an Int (I think, need to double check), which is not quite enough to be useful.
Underlying clock accuracy will not really be ns.
I might look at this and propose something.
I am ok with any precision of at least a millisecond... trying to play with animations. I have fixed it to nanoseconds locally, but will wait to see what you decide before making a PR.
Haskell's time
package provides a 64-bit signed integer representing seconds relative to the 1970 epoch, + an additional 32-bit unsigned integer representing nanoseconds. I'd propose having the unison builtin do the same.
There's also... microseconds? Which lets us talk about 1970 +/- 280,000 years. Fits in an Int
.
That would be my vote. Clock granularity and thread scheduling (via delay
) isn't nanos precision anyway. If at some point in the future nanos granularity is a thing, that could be a new builtin.
If you're talking about time for a black hole to evaporate via Hawking radiation or something, systemTime
is not for that and you roll your own type. :)
Microseconds would work for me!
I think we should also change EpochTime (which is the thing we're talking about) from Nat to Int. So we can talk about times before 1970. That would ratchet up the friendliness of the datetime library several notches - at the moment it needs the user to convert to its own signed wrapper type, which is painful.
Sounds good.
Okay, I'd suggest we introduce a new builtin, systemTime.v2
(it can still be given the name systemTime
in base), which returns an Int
microseconds. And the old one can just be deleted I'd say since I don't think seconds granularity is very useful and unlikely to be what people want. You can always get seconds back from microseconds. :)
@alvaroc1 if you want to draw up a PR we can review. :)
the old one can just be deleted
To clarify, this means deleted from base
, not from ucm.
On trunk (prob other versions too):
the seconds are coming from the underlying built-in
systemTime.impl