[Haskell-cafe] Towards a better time library (announcing tz)

[Mihaly Barasz]

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:utcToLocalTimeTZ
[5]  http://hackage.haskell.org/package/timezone-series
[6]  http://hackage.haskell.org/package/timezone-olson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140331/6d13997c/attachment.sig>