[tz] Issues with pre-1970 information in TZDB

Brooks Harris 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)
> 	Debian
> 	macOS
> 	FreeBSD
> 	OpenBSD
> 	NetBSD
> 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 mailing list