Hey guys,
Hope everyone is ok!
Is it possible to change the ledger timezone? wall-clock-time sets it to UTC, but what if I want my ledger to be in another timezone?
Thanks!
Hi Guido!
The ledger itself has no timezone. Each participant runs with their own wall-clock time, which for simplicity is on UTC. In general, making timezone a server-side concern can lead to very weird situations (most likely during DST transitions).
With that said, you may be interacting with applications that send you times that have some timezone, but in that case I would recommend requiring clients to either normalize times to UTC or send the timezone alongside the time and normalize on the server. Would that be an approach you can use? Otherwise, can you go a bit deeper with regards to your use case?
1 Like
Hi Stefan,
In our case it’s quite the opposite. We’re sending generated events from the ledger to client applications. Our timezone is UTC +1, which means that sometimes, if we have an event for 15 minutes after current hour, what the client app gets is an event in the past. So, as a workaround, should I transform the time coming from the ledger to the correct timezone on the server side?
The Ledger API encodes all Daml Times purely as a timestamp with the number of microseconds since the standard epoch of 1970-01-01T00:00:00Z and if by chance you are using the Java bindings/codegen those are in turn deserialized into java.time.Instant objects, which represent the same concept (but with nanosecond granularity). The Protobuf type mappings are documented here and the Java codegen type mappings documented here).
When treating those values on your server- and client-side applications interacting with the ledger, you should compare them with only with types that match those properties. One possible approach, is to ensure that both the timestamp coming from the ledger and a possibly “zoned” time on the application are normalized to a common timezone, as you mentioned in your post.
In general when dealing with time I believe the simplest approach is to work with epoch-based timestamps (or perhaps objects that wrap that concept) and only apply timezone offsets when it’s important to the end user to contextualize that information (usually on a client-side app, where the timezone is known and clear), although as usual YMMV. 
1 Like