Guy Harris <guy@alum.mit.edu> writes:
By either
1) using your own un-winnowed version of the tzdb
or
2) only using systems where the vendor guarantees that they're offering an un-winnowed version of the tzdb, if there are any such systems.
An obvious approach for distribution packagers would be to provide two packages that both Provide tzdata, one with the traditionally winnowed data (1970 cutoff) and one with the full data, and let people pick. The one winnowed to 1970 would probably be the one installed by default, unless the number of additional zones in the unwinnowed version turned out to not be significant. I suspect that initial installs would provide only the winnowed data for initial time zone selection, since that's where a multitude of choices poses the largest UI concern. One very interesting thing that this proposal offers, which is not currently available, would be to build a custom set of tzdata for the install process that's better-suited to the UI needs of initial installation and time zone selection. For example, for installs, I could see deciding to include only zones whose differences matter for current time (a cutoff of 2013), but including the data set that ensures that every ISO 3166-1 code has at least one zone because the geopolitical issues are particularly acute during the install process. (Of course, one would have to be careful that one didn't drop the selected zone if one switched to a database with a different winnowing property, or provide some mapping mechanism.) -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>