Joe Healy wrote:
One of the points I found "non obvious" were the fact that local time is just that. There is no knowledge of the actual timezone in the data type. If you wish to store that, it needs to be stored alongside.
Erik Hesselink wrote:
Isn't that what ZonedTime [1] is for?
Not exactly. A "TimeZone" in Data.Time doesn't really represent a time zone - it represents a specific clock setting in a time zone. Clock settings periodically change in a time zone - e.g., to or from summer time, or due to government decree. A ZonedTime is a LocalTime together with a specific clock setting in a time zone. There is no guarantee that the clock setting was actually in effect at the given LocalTime. So a ZonedTime is only useful if you have checked separately that it is consistent, or if you don't care. ZoneSeriesTime in the timezone-series package[1] more accurately represents a moment in time in a given time zone. There the moment is represented as a UTCTime, not a LocalTime. The reason is that a LocalTime in a time zone does not necessarily represent a unique moment. When the LocalTime happens to be near a clock change, it can represent zero moments or more than one moment. To get the LocalTime from a ZoneSeriesTime, use the function zoneSeriesTimeToLocalTime. To get a TimeZoneSeries, representing a time zone with all of its known clock changes throughout history and some years into the future, use the timezone-olson package[2] to read an Olson time zone file. On Linux and Mac OS X systems, Olson time zone files are available in the directory /usr/share/zoneinfo. -Yitz