During the spring and the fall, governments tend to mess with their clocks a lot, and this prompts frequent updates to tzdata package to reflect all this. We would like the users to actually see those changes in time, but this rarely happens. tzdata is a critical-path package, and as such, it must go through testing before it is allowed to stable. As a result, we never really ship stable data in time, clocks are wrong, and people file bug reports, because it doesn't occur to them that the right data might be in testing.

It is true that tzdata is one of the fundamental packages of the system that even glibc depends on. However, it's just data, not code, and changes in those data are unlikely to break libc. The data that I package are almost always reviewed by upstream first, and tested by people coming from all around UNIX. In addition, I test the data by doing pure data-based comparison using tzdiff (a tool that is hosted here on Fedora Hosted, though not packaged) to make sure there's nothing outlandish there. Finally, changes are minimal and localized, there's simply no way the change would somehow poison the whole package*.

(* except for the grand changes like the introduction of 64-bit time stamps. These are rare and I could always opt to push such changes to testing first.)

True, it's not strictly unthinkable that broken tzdata exposes libc bugs. If this should happen, the impacted user would have to remove the file /etc/localtime. libc would then revert to UTC and things would work again. I'm not sure whether booting to single-user mode would work in face of this though. So perhaps the spell in testing is justified?

No, not really. The assumption that tzdata is actually tested in testing is wrong. People add karma and drop lines such as "works here on casual testing" etc., which most probably really just means, "I installed it, and it doesn't break my U.S. or European zone". Well, that doesn't really help for updates related to Russia, Ukraine or Brazil. Even if the person was from the right locale, they would have to test the DST transition/zone change that we fix for the test to be meaningful, and I don't think anyone actually does that, apart from Red Hat QE for RHEL. But if I was to wait for relevant tests to come in, tzdata would be in perpetual testing, because, frankly, there are not that much avid users in, say, Ukraine. (Note that I got two reports related to the lack of support of the latest Ukraine change. There are users impacted by this, and they are avid enough to file bugs, they are just not avid enough to know about testing).

On the other hand, older or even too new Fedora releases take a long time to get the karma necessary for auto-push. Or even the first karma point that I need for manual marking. Pushing the currently supported release is not all that big of a deal compared to waiting for F14 (as of writing this) to be noticed. But it's the same data, the probability that F15 is correct and F14 somehow broken is slim to none.

To sum it all up, I don't think that pushing tzdata to testing serves the purpose it's supposed to serve. Besides, I argue that it's not likely that tzdata actually breaks the system in the first place. I would therefore like to propose that tzdata is removed from the set of critical path packages, and is allowed to be pushed directly to stable. That would allow us to keep up with the changes that governments make.

Alternatively, I might just do the testing and karma myself, but that would just prove that the spell in testing is worthless. I already know it works on my system.