The new timezone-series and timezone-olson packages provide enhancements to timezone processing in Haskell's time package, Data.Time. http://hackage.haskell.org/package/timezone-series http://hackage.haskell.org/package/timezone-olson These enhancements are related to the fact that the Data.Time.TimeZone data type does not fully represent a timezone - it only represents a specific clock setting for a timezone, as is traditional for time APIs. But that leads to a number of limitations, such as: o For utcToLocalTime and localTimeToUTC, it is up to the user to ensure that the TimeZone and time specified are consistent with each other. These functions can give wrong results if the specified clock setting was not actually in effect at the specified moment in the given timezone. o It is difficult to compute the amount of time between two moments expessed in terms of the local clock, because you need to know the history of clock changes that happened in between. o When a ZonedTime is constructed, it is up to the user to ensure that its components are consistent with each other and make sense. o Given a ZonedTime, there is no way to construct another ZonedTime for a different moment in the same timezone, unless you know that the same clock setting is in effect at the new moment. Besides those issues - it's just nice to have a type that truly models a timezone. The timezone-series package introduces two new datatypes: TimeZoneSeries, which represents a timezone with all of its clock settings and when each is in effect, and ZoneSeriesTime, which represents a moment within a specific timezone. This package also includes variants of utcToLocalTime and localTimeToUTC which take a TimeZoneSeries instead of a TimeZone as parameter and always give the correct result. The timezone-olson package provides a pure Haskell parser and renderer for binary Olson timezone files. That provides an easy way to create rich TimeZoneSeries objects for most of the timezones of the world on many platforms. I have tried to write these packages in a way that is consistent as much as possible with Data.Time - naming conventions, providing expected services such as ParseTime and FormatTime instances, etc. These packages are distributed on Hackage under a BSD3 license. Caveats: o These packages contain preliminary versions of the software and should be considered highly experimental. Expect there to be bugs, and do not rely on any stability of the exposed interfaces at the moment. o So far, there is no easy solution for Windows users to create a TimeZoneSeries. On Windows, timezone series information is in the registry in a propreitary format, and I don't have a parser for that at the moment. In the meantime, Windows users can copy the Olson files from a Unix system, or compile the Olson files themselves from the zoneinfo sources. I hope to have a much better solution in the near future, and, of course, contributions are welcome. o There is not yet a truly platform-independent way of finding the Olson files for Unix-like platforms. Nowadays /usr/share/zoneinfo is a very popular location for them, but some platforms have them elsewhere. o getCurrentTimeZone is still the best way to get the "official" clock setting for the current moment on the local computer for the local time zone, or for whatever time zone you fool the OS into thinking that you are in. There is also Mark Aylett's zoneinfo package. Those bindings to the C API give you clock settings that are most likely to be consistent with what is used by other apps on the same local computer. But the C API gives you a clock setting, not a timezone. And the system timezone database on the local computer could be out of date. And the interface, which involves setting global process state and then calling effectful procedures, is awkward to say the least and prone to cause trouble. So I think it's nice to have a pure Haskell Olson parser. I would like to take this opportunity to thank once again Ashley Yakely for his fantastic work in creating Haskell's advanced time API in Data.Time. Enjoy, Yitz