[tz] Issues with pre-1970 information in TZDB
brooks at edlmax.com
Wed Sep 22 23:25:28 UTC 2021
On 2021-09-22 7:02 PM, Tom Lane via tz wrote:
> I wrote:
>> 2. This approach puts it on individual tzdb distributors to decide
>> which of these two options to choose. Some will choose differently
>> than others, meaning we'll now have two received versions of tzdb,
>> which is as bad as a fork from the perspective of end users.
>> (It was argued that we already have problem #2 because some distributors
>> already use backzone. AFAICT that's only a small minority though.
>> It'd likely become a much bigger issue.)
> To put some detail on that claim ... I ran around and checked systems
> I had handy to see whether the vendor-provided tzdb includes backzone.
> I checked this by seeing whether Africa/Timbuktu contained different
> data from Africa/Abidjan, which hasn't been true since 2014f unless
> you built with backzone. (Some of the system images I checked are a
> year or two old, but it seems unlikely that any vendors would have
> changed their policies recently.) Of
> Red Hat (both Fedora and RHEL)
> not one is building with backzone. I think it's reasonably safe to
> assert that the current population of backzone users is negligible.
> (Of course, Windows would be the elephant in the room here, but last
> I heard Windows uses their own timezone database not tzdb.)
> regards, tom lane
As I understand it Windows uses tzdb as filtered through CLDR:
So its "based on" tzdb source data but is a sub-set of tzdb time zones
mapped to reverse compatible Windows "time zones". I don't believe it
supports any pre-1970 data.
More information about the tz