I would like to propose reforming the 'time' [1] library. Initially, I was just planning to announce my new 'tz' [2] library, but realized that I have a more important agenda. Namely: Haskell needs a better time library! Let me summarize what are ‒ in my view ‒ the biggest deficiencies of 'time': 1. Inefficient data structures and implementations. 2. Ad-hoc API which is hard to remember and frustrating to work with. 3. Conceptually wrong representations and/or missing concepts. The wonderful thyme [3] package (by Liyang HU) improves a lot on #1 by choosing better data structures and careful implementations and on #2 by lensifying the API. But, it was the #3 that caused me the most frustration lately; most importantly the time zone handling. There is a TimeZone data type in 'time', but it is a misnomer, it basically represents a fixed time difference (with a label and a DST flag). 'time' basically adapts the broken approach from libc: you can work with one time zone at a time, which is defined globally for your program (via the TZ environment variable). So, the transformation between UTCTime and LocalTime which should have been a pure function can only be done in IO now. Like this: do tz <- getTimeZone ut return $ utcToLocalTime tz ut Oh, and just to hammer down on the point #1 from the list above. This code runs in about 6100 ns on my machine. The drop-in replacement from tz: utcToLocalTimeTZ [4] (which is actually pure) runs in 2300 ns. While this is a significant improvement, it's easy to miss the point where the bulk of the inefficiency comes from the data structures. In my main project we represent times as Int64 (raw nanoseconds since UNIX epoch; and similar representation for zoned times). And to convert those to and from different time zones we need 40 ns. That's right, a 150 _times_ improvement! (There are many other interesting benchmark results that I could mention. An exciting bottom line: we can actually beat the libc in many use-cases!) The 'tz' package is still very much in flux. I will try to solidify the API soon, but until then it should be considered more of a proof of concept. There is some missing functionality, for example. On the other hand, there are the 'timezone-series' [5] and 'timezone-olson' [6] packages that together provide about the same functionality as 'tz' (minus the efficiency), and I'd like to explore if we could remove some of the overlap. But, all kind of suggestions and requests are welcome! More importantly, I'd like to hear the opinions of the community about the general issue of a better time library! Do we need one? How should we proceed about it? I think, Haskell could potentially have one of the best time libraries, but the current de-facto standard is mediocre at best. Unfortunately, designing a good time library is very far from trivial, as many existing examples demonstrate. And I definitely don't know enough for it. (I understand time zone info files, now that I wrote tz, but that's just a tiny fraction of what's needed.) So, if you think you can contribute to the design (have important use-cases in mind, know good examples of API, have some experience working with dates and time, etc. etc.) ‒ speak up! Mihaly Footnotes: [1] http://hackage.haskell.org/package/time [2] http://hackage.haskell.org/package/tz [3] http://hackage.haskell.org/package/thyme [4] http://hackage.haskell.org/package/tz-0.0.0.1/docs/Data-Time-Zones.html#v:ut... [5] http://hackage.haskell.org/package/timezone-series [6] http://hackage.haskell.org/package/timezone-olson