# Time with millisecond precision

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?

1 Like

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.

2 Likes

`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)
``````
4 Likes

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.

1 Like

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