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

Mihaly Barasz klao at nilcons.com
Tue Apr 8 14:23:18 UTC 2014


>> I don't think you really need to do this, it was just a minor
>> suggestion I made. As long as it's mentioned in the package and module
>> documentation what tz database version is being used, it should be
>> fine.
>
> I might do it anyway. It's a nice separation, and also others who
> don't want to use `TZ` (like `timezone-olson`) might benefit from it
> too.

I have separated the "data" part into a separate `tzdata` package:
http://hackage.haskell.org/package/tzdata
It should be completely `tz` agnostic and suitable for use with
`timezone-{olson,series}` packages too.

I have adopted Renzo's updated versioning suggestion:
`A.B.YYYYMMDD.C`, where `A.B` describes the Haskell API as usual, and
YYYYMMDD the official release date of time zone database contained.
This way you normally specify only a `>= A.B` dependency and get the
latest data released with the API you can handle. But you _can_ also
specify that you need "fresh" time zone data if you _want_ to.

Also, some numbers (which I only sent to Renzo by mistake):

If you depend on Data.Time.Zones.All, you binary size increases by
about 2M. (Of course, if you don't import it just use the rest of
the package, you don't pay anything.)  I don't know why is it so much,
the data itself is less than 450k. I will look into it later.

The memory usage increases by about 900k if you use _all_ of the time
zones. But, because they are all parsed lazily, you only pay for what
you use. If you don't touch any of the TZs, you don't pay anything in
memory. (And this 900k is probably fair: the in-memory representation
of `TZ` is not that compact. But, I have a few ideas how to improve on
that.)

Mihaly


More information about the Haskell-Cafe mailing list