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?
I noticed that the
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.
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),
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
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