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?

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.

bernhard:

relTimeSinceEpochUTC

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

gtpaulose2:

Is there a reason why the above functions aren’t in a standard lib? I

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