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