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 _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
