Tz/tzdata not maintained

Learn
#1

Does somebody know how to get in touch with the maintainers of tz/tzdata? They seem to be Hungarian and worked together in an organization called Nilcons. The latest tzdata has a version that suggests it uses the IANA tzdb from October 2020. So it hasn’t been updated for more than a year.

Furthermore, I would like to get in touch with other users of these packages so that we can coordinate. I was thinking of applying to take over maintainership but Oleg Grenrus advised me against it. But if the authors do not respond before March, I think I’ll apply for the maintainership since it would be nice to have an updated timezone database before Daylight Savings Time starts.

My first PRs were submitted in November 2021 and I still have not received any replies: Pull requests · nilcons/haskell-tzdata · GitHub

I’d welcome any advice! If any highly trusted member of the community wants to take over maintainership, of course that would be even better. I am not maintaining any packages yet, so I may lack the experience. These packages are moderately popular: tzdata had 136 downloads in the last month, according to Hackage.

5 Likes
#2

According to Taking over a package you are doing everything correctly (i.e. “State your intention to take over the package in a public forum”). Now it is time to wait a bit and then — if nothing moves — contact hackage admins.

2 Likes
#3

I recommend not using the compiled-in database. I use loadSystemTZ (from the tz package) to get zone information from the system database. That way, I don’t have to rebuild my application to take advantage of tzdata updates, which sometimes come in quite late before the next DST change.

4 Likes
#4

Using loadSystemTZ also means that you have to make sure that the system tzdb doesn’t use the slim format, since tz cannot handle that (imagine running the test suite on a machine that has a different tzdb than the production machine!). I think it makes a lot of sense to have the tzdb built in as a library (that you can pin), since that is how reproducability is commonly achieved. Resolving timezones at runtime is like any other IO at runtime, which is not how most libraries work.

A third option is to resolve the tzdb at compile time using e.g. timezone-olson-th.

I think the tzdata approach is the most reliable.

1 Like
#5

imagine running the test suite on a machine that has a different tzdb than the production machine!

We did actually make that mistake at one point. However, that’s no different to running the test suite with different shared libraries. We now consider the OS tzdata package to be part of the OS-level dependencies and we install it explicitly in the shared Docker image we use for local dev (via Stack’s Docker support), CI and production. If the tzdata format changes, we find that out during QA when we upgrade to a newer OS base release.

Pinning the tzdata inside the Haskell binary does have advantages, but you’re then dependent on the upstream library integrating tzdata updates (as you are now) or using your own fork of the library. Another pinning approach is to ship your own copy of the tzdata files as part of the application, but still reading them at runtime. This avoids having a custom build of tz but still gives you complete control of pinning.

2 Likes