I noticed that the Time
type only supports resolution to the second. What’s the rationale to limiting this and is the suggested approach here to define my own type if I need higher resolution? Or is there another type I didn’t see?
Since Time
is directly based on a primitive built-in LF type, it’s generally better for the stability and compatibility of future changes to be as conservative as possible with regard to what’s allowed.
The question of what Time
supports is really one of “what is needed of a primitive LF time construct?”, rather than “what features of time might be useful in applications?”, so the best approach is certainly to define your own type if you have different requirements.
Time
and RelTime
in DAML are stored to microsecond precision, and there is a function convertRelTimeToMicroseconds
to extract the microseconds from RelTime
. If we ignore time zones, you can then write the following functions:
module Main where
import DA.Assert
import DA.Time
import DA.Date
epoch : Time = datetime 1970 Jan 1 0 0 0
microsInSecond : Int = 1000000
microsInMinute : Int = 60 * microsInSecond
microsInHour : Int = 60 * microsInMinute
microsInDay : Int = 24 * microsInHour
relTimeSinceEpochUTC (t : Time) : RelTime =
subTime t epoch
timeToMicrosSinceEpochUTC =
convertRelTimeToMicroseconds . relTimeSinceEpochUTC
wholeHours (r : RelTime) =
((convertRelTimeToMicroseconds r) % microsInDay) / microsInHour
wholeMinutes (r : RelTime) =
((convertRelTimeToMicroseconds r) % microsInHour) / microsInMinute
wholeSeconds (r : RelTime) =
((convertRelTimeToMicroseconds r) % microsInMinute) / microsInSecond
remainingMicros (r : RelTime) =
(convertRelTimeToMicroseconds r) % microsInSecond
decomposeDateTime (t : Time) : (Int, Month, Int, Int, Int, Int, Int) =
( y, mon, d, h, min, s, micros)
where
(y, mon, d) = toGregorian (toDateUTC t)
r = relTimeSinceEpochUTC t
h = wholeHours r
min = wholeMinutes r
s = wholeSeconds r
micros = remainingMicros r
template Timer
with
p : Party
where
signatory p
controller p can
GetTime : Time
do
getTime
deriving instance Show (Int, Month, Int, Int, Int, Int, Int)
setup = scenario do
p <- getParty "p"
cid <- submit p do
create Timer with ..
pass (convertMicrosecondsToRelTime 1590736235123456)
submit p do
decomposedTime <- decomposeDateTime <$> exercise cid GetTime
assertEq decomposedTime (2020, May, 29, 7, 10, 35, 123456)
Thanks for the clarification @bernhard. This is certainly not clear from the docs, nothing there indicates that Time
in fact does have microsecond resolution. Maybe some more helper functions in the stdlib would make this more user-friendly.
Is there a reason why the above functions aren’t in a standard lib? I would have thought the ability to convert time to it’s corresponding epoch time would be less verbose then defining (at minimum),
epoch
and relTimeSinceEpochUTC (t : Time) : RelTime
Of course omitting timezone
Yes, we don’t want to lead developers to try to work with time at microsecond precision as that precision leads to an illusion of accuracy. Time in a distributed system is a fuzzy concept and that is true for the time you get from getTime
as well. While it has microsecond precision, it’s only accurate to a within a few seconds or even minutes. Its accuracy is determined by the skew parameters documented here.
That documentation section also explains that within that window defined by the skew parameters, the submitting participant has some freedom in choosing the ledger time returned by getTime
.
To stop developers falling into the trap of trying to use microsecond time for random number generation, or relying on the relative timings of events at that level or precision, we made it convenient to work with time at second and minute precision, but included no helpers for anything more precise.
Fair enough, that makes sense. Thank you