Since the tzdata 2021c release removed most of the controversial link changes, I wonder how other downstreams feel about importing it. I spent some time this morning looking at the downstreams I know about. FreeBSD has 2021c in main but is still on 2021a plus Samoa and Jordan in the supported stable branches. Debian is in the same state as FreeBSD. NetBSD, OpenBSD and Ubuntu are on 2021a + Samoa and Jordan. Fedora is on 2021b. CentOS is on 2021a. A casual glance at other Linux distributions shows they are either on 2021a or 2021c. I am not familiar with their support models so I can't read anything into that. Python "pytz" seems to be on 2021c. Python "tzdata" seems to be in a similar state to FreeBSD, though I'm not sure I'm interpreting the release model correctly. I know Paul G is on this mailing list though. As far as I can tell, PostgreSQL is still on 2021a without modifications for Samoa and Jordan. Tom will correct me if I'm reading that wrong. I don't know enough about PHP, Java or any of the other well-known (let alone less well-known) downstreams to figure out what they're doing. This is looking terribly fragmented. Spare a thought for a hypothetical engineer tasked with debugging a Java application on Debian with some Python scripts on Fedora talking to a PostgreSQL database running on FreeBSD... While discussions on this list appear to have become more constructive, it looks like we're still lacking a clear consensus on the long-term direction. I feel that 2021c is a pretty reasonable compromise and would be willing to merge it to the supported FreeBSD releases. Is this something other downstreams would consider too? Alternatively, can we reach an interim consensus for a 2021d release that we'd all be willing to merge? Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
What I've done for Python's tzdata so far is that I released 2021.2 as 2021a+Samoa+Jordan, then I immediately made a 2021.2.post0 release that is just a straight repackaging of 2021b. In Python's system it's not too hard to explicitly rule out a version (i.e. depend on "tzdata != 2021.2.post0"), so I figured this was the "best of both worlds" approach. I haven't repackaged 2021c yet because it seems like most of the major bugfixes in 2021c are fixes to regressions that happened between 2021a and 2021b, so anyone who is affected by these can use tzdata != 2021.2.post0, and I didn't want to continue maintaining this two-track versioning system (since blacklisting a single revision is not much of a pain, but blacklisting a sequence of revisions is a lot more annoying). If the removal of "most" of the controversial link changes is enough for the crowd upset by the changes in 2021b, it would certainly be nice to go back to just automatically cutting binary releases from the release tarballs... Best, Paul On 10/7/21 00:26, Philip Paeps via tz wrote:
Since the tzdata 2021c release removed most of the controversial link changes, I wonder how other downstreams feel about importing it. I spent some time this morning looking at the downstreams I know about.
FreeBSD has 2021c in main but is still on 2021a plus Samoa and Jordan in the supported stable branches.
Debian is in the same state as FreeBSD. NetBSD, OpenBSD and Ubuntu are on 2021a + Samoa and Jordan. Fedora is on 2021b. CentOS is on 2021a. A casual glance at other Linux distributions shows they are either on 2021a or 2021c. I am not familiar with their support models so I can't read anything into that.
Python "pytz" seems to be on 2021c. Python "tzdata" seems to be in a similar state to FreeBSD, though I'm not sure I'm interpreting the release model correctly. I know Paul G is on this mailing list though.
As far as I can tell, PostgreSQL is still on 2021a without modifications for Samoa and Jordan. Tom will correct me if I'm reading that wrong.
I don't know enough about PHP, Java or any of the other well-known (let alone less well-known) downstreams to figure out what they're doing.
This is looking terribly fragmented. Spare a thought for a hypothetical engineer tasked with debugging a Java application on Debian with some Python scripts on Fedora talking to a PostgreSQL database running on FreeBSD...
While discussions on this list appear to have become more constructive, it looks like we're still lacking a clear consensus on the long-term direction.
I feel that 2021c is a pretty reasonable compromise and would be willing to merge it to the supported FreeBSD releases. Is this something other downstreams would consider too?
Alternatively, can we reach an interim consensus for a 2021d release that we'd all be willing to merge?
Philip
Philip Paeps via tz <tz@iana.org> writes:
As far as I can tell, PostgreSQL is still on 2021a without modifications for Samoa and Jordan. Tom will correct me if I'm reading that wrong.
As far as Postgres is concerned, I've not done anything yet because it won't matter until our next quarterly releases in early November (unlike many of the other projects you mentioned, we don't do any sort of rolling release). So 2021a is still what's in our git tree, but most likely I'll push in 2021c before November (or 2021d, if that appears by then). We will definitely not be adopting 2021b. Having said that, I think what we ship in our releases affects only a minority of production users anyway. Our normal advice for production builds is to configure with --with-system-tzdata and rely on your platform vendor to keep the TZ data updated, if you're on a platform where that receives regular updates. So the actual state of Postgres databases in the field is probably just about as messy as you depicted.
This is looking terribly fragmented. Spare a thought for a hypothetical engineer tasked with debugging a Java application on Debian with some Python scripts on Fedora talking to a PostgreSQL database running on FreeBSD...
Indeed :-( regards, tom lane
Philip Paeps via tz <tz@iana.org> writes:
This is looking terribly fragmented. Spare a thought for a hypothetical engineer tasked with debugging a Java application on Debian with some Python scripts on Fedora talking to a PostgreSQL database running on FreeBSD...
BTW, that brings a thought to mind: why isn't there an easy way to identify the release version of an installed tzdata tree? I'm envisioning that there could be a text file at the top level, say /usr/share/zoneinfo/version in typical layouts, containing "2021a" or the appropriate string. This'd make it a lot easier to diagnose what you've got in a particular installation. Some vendors (Red Hat at least) include the tzdata.zi file in /usr/share/zoneinfo. I persuaded Paul awhile back to put a version comment at the top of that, so that provides a way to determine the version if your vendor did that. But it seems like a mighty redundant approach. regards, tom lane
On 10/7/21 10:00 AM, Tom Lane via tz wrote:
why isn't there an easy way to identify the release version of an installed tzdata tree?
$ head -n 1 /usr/share/zoneinfo/tzdata.zi # version 2021b I ran this shell command on my Fedora 34 system, which I updated a few days ago from the Fedora project by using the "dnf update", a standard way to keep up-to-date. Unfortunately this tzdata.zi approach is not taken by every distribution. Also, it's reasonably common for distributions to say "2021b" (or whatever) even though the actual data contains minor modifications from vanilla 2021b. The modifications are typically so minor that almost nobody cares about the differences (though evidently somebody does :-).
Someone pointed out that there is not necessarily just the one version of the tzdb represented in the compiled/installed binary files. I'll note that there are "fifteen bytes containing zeros reserved for future use" starting at the 6th byte of the tzfile(5) binary format. Perhaps some of that could be used to carry the version of the source data? If downstream mods add their own suffix, it makes it easier to identify which compiled zones came from which source. On Thu, Oct 7, 2021 at 10:21 AM Paul Eggert via tz <tz@iana.org> wrote:
On 10/7/21 10:00 AM, Tom Lane via tz wrote:
why isn't there an easy way to identify the release version of an installed tzdata tree?
$ head -n 1 /usr/share/zoneinfo/tzdata.zi # version 2021b
...
-- Alan Mintz <Alan.Mintz@gMail.com>
On 10/7/21 15:54, Alan Mintz via tz wrote:
there are "fifteen bytes containing zeros reserved for future use" starting at the 6th byte of the tzfile(5) binary format. Perhaps some of that could be used to carry the version of the source data? If downstream mods add their own suffix,
That's been proposed before. Unfortunately, it's likely that version strings would exceed 15 bytes in length, given downstream needs. For example, the tzdata package on my workstation is named "tzdata-2021b-1.fc34.noarch" and I've seen longer. Also, as a rule I've found that putting a version number into every file (or every line of every file) to be overkill. It's generally better to have at most one version number per thing versioned.
El oct. 7, 2021, a las 6:12 p. m., Paul Eggert via tz <tz@iana.org> escribió:
On 10/7/21 15:54, Alan Mintz via tz wrote:
there are "fifteen bytes containing zeros reserved for future use" starting at the 6th byte of the tzfile(5) binary format. Perhaps some of that could be used to carry the version of the source data? If downstream mods add their own suffix,
That's been proposed before. Unfortunately, it's likely that version strings would exceed 15 bytes in length, given downstream needs. For example, the tzdata package on my workstation is named "tzdata-2021b-1.fc34.noarch" and I've seen longer.
Also, as a rule I've found that putting a version number into every file (or every line of every file) to be overkill. It's generally better to have at most one version number per thing versioned.
In implementations, the single file ( such as America/Chicago ) is often only available by itself, with no context. /etc/localtime may be a hard link to somewhere, or simply copied from some random location. So yes, having the version on every single binary file would be the most useful, given the way these files are used. I also proposed that the files contain their ids internally (America/Chicago) for the same reason. Perhaps there’s some way to recode this information into 120 bits. -s
I also think a better story for versioning in the binaries would be very nice to have, though the fact that TZif is designed such that you can have arbitrary TZif files generated from something other than TZDB and the fact that people deploy forks makes things a lot more complicated. For some context, previous discussions on this that I know about: From 2015: https://mm.icann.org/pipermail/tz/2015-October/022807.html (That thread gets fragmented, so looking at the "October 2015" view might be best to see the whole thread) From 2018: https://mm.icann.org/pipermail/tz/2018-July/026645.html I'll note that IIRC the tzdata.zi file with version comment and the `make version` file resulted from or at least came after that 2015 thread, and I've seen a lot wider adoption of shipping tzdata.zi, so it's much easier to get the data version on most platforms today than it has been in the past. Best, Paul On 10/7/21 13:00, Tom Lane via tz wrote:
Philip Paeps via tz <tz@iana.org> writes:
This is looking terribly fragmented. Spare a thought for a hypothetical engineer tasked with debugging a Java application on Debian with some Python scripts on Fedora talking to a PostgreSQL database running on FreeBSD... BTW, that brings a thought to mind: why isn't there an easy way to identify the release version of an installed tzdata tree?
I'm envisioning that there could be a text file at the top level, say /usr/share/zoneinfo/version in typical layouts, containing "2021a" or the appropriate string. This'd make it a lot easier to diagnose what you've got in a particular installation.
Some vendors (Red Hat at least) include the tzdata.zi file in /usr/share/zoneinfo. I persuaded Paul awhile back to put a version comment at the top of that, so that provides a way to determine the version if your vendor did that. But it seems like a mighty redundant approach.
regards, tom lane
On Oct 7, 2021, at 10:00 AM, Tom Lane via tz <tz@iana.org> wrote:
BTW, that brings a thought to mind: why isn't there an easy way to identify the release version of an installed tzdata tree?
I'm envisioning that there could be a text file at the top level, say /usr/share/zoneinfo/version in typical layouts, containing "2021a" or the appropriate string. This'd make it a lot easier to diagnose what you've got in a particular installation.
$ cat /usr/share/zoneinfo/+VERSION 2021a OK, so what is that UN*X? $ uname -sr Darwin 20.6.0 So what does that mean? $ sw_vers ProductName: macOS ProductVersion: 11.6 BuildVersion: 20G165 Your mileage will vary on other UN*Xes; I think +VERSION may be an Appleism (Deborah?), and I don't know when it was first provided.
Guy Harris <gharris@sonic.net> writes:
On Oct 7, 2021, at 10:00 AM, Tom Lane via tz <tz@iana.org> wrote:
I'm envisioning that there could be a text file at the top level, say /usr/share/zoneinfo/version in typical layouts, containing "2021a" or the appropriate string. This'd make it a lot easier to diagnose what you've got in a particular installation.
$ cat /usr/share/zoneinfo/+VERSION 2021a
Interesting ... and in fact, Apple's labeling it in another way too, because I see this on my Mac laptop: $ ls -l /usr/share/zoneinfo/ lrwxr-xr-x 1 root wheel 38 Sep 13 19:15 /usr/share/zoneinfo/ -> /var/db/timezone/tz/2021a.1.0/zoneinfo But that pretty much just begs the point, which is that there's no *standard* cross-platform way to get this info. On my RHEL workstation, I don't see any identification info except the first line of tzdata.zi, which isn't a standard inclusion either. (Of course, I can consult the RPM package database to find out the version of the tzdata package ... still more platform dependency.) My point isn't whether it's possible to figure this out on any given platform, but that tzdata itself ought to define a standard way to find it out. And I do not agree with Paul's opinion that "include tzdata.zi" is a good enough answer; lots of platforms won't care to expend the disk space to do it that way. (But, in view of Apple having already done it like that, maybe there's something to be said for using +VERSION as the file name.) regards, tom lane
Tom Lane via tz <tz@iana.org> writes:
My point isn't whether it's possible to figure this out on any given platform, but that tzdata itself ought to define a standard way to find it out. And I do not agree with Paul's opinion that "include tzdata.zi" is a good enough answer; lots of platforms won't care to expend the disk space to do it that way.
tzdata.zi is 112KB out of 7.2MB total size (1.7MB apparent size which doesn't count file system overhead) in /usr/share/zoneinfo on my Debian system. Yes, it's larger than a simple version file, but it doesn't seem that significant on anything other than small embedded systems where I'm not sure the entire tzdata database would be desired anyway. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
On 10/7/21 13:10, Russ Allbery via tz wrote:
tzdata.zi is 112KB out of 7.2MB total size
And tzdata.zi is only 22,577 bytes when compressed with 'lzip -9'. I was a bit taken aback just now, when I realized that all of tzdb can be compressed into a size that would nearly fit into the RAM of the first computer I ever programmed, a circa-1961 GE-225 mainframe that weighed nearly a ton and had only 8192 20-bit words. https://www.redhat.com/en/command-line-heroes/season-4/mainframes
Paul Eggert via tz said:
I was a bit taken aback just now, when I realized that all of tzdb can be compressed into a size that would nearly fit into the RAM of the first computer I ever programmed, a circa-1961 GE-225 mainframe that weighed nearly a ton and had only 8192 20-bit words.
The first machine I programmed had only 8192 words, well actually 8188 [1], but they did have 39 bits each rather than 20. I can't find the weight of the model we had, but the minimal system (with 4092 words) was just over 800 kg. [1] All 8192 words were present, but four of them couldn't be accessed: the addresses went to a 4 word ROM instead. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On 10/7/21 13:00, Tom Lane via tz wrote:
maybe there's something to be said for using +VERSION as the file name
Unfortunately the POSIX portable filename character set lacks '+'. https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag... Perhaps Apple used "+VERSION" so as to not collide with any portable filename. Admittedly, installed filenames like "Etc/GMT+10" already use "+" and nobody seems to mind. Though perhaps the people who would mind are not using the "etcetera" file (as it's kinda optional) and thus are sidestepping the issue.
FYI, 2021a.1.0 just refers to 2021a. Apple released what ICU called 2021a1 as 2021a.2.0. The +VERSION file for that is still 2021a. You probably already have 2021a.2.0 downloaded; you can check via: % ls -l /var/db/timezone If so, rebooting will make it the active version of tzdb. See this page for an overview: https://support.apple.com/en-us/HT206986 Deborah
On Oct 7, 2021, at 1:00 PM, Tom Lane via tz <tz@iana.org> wrote:
Guy Harris <gharris@sonic.net> writes:
On Oct 7, 2021, at 10:00 AM, Tom Lane via tz <tz@iana.org> wrote:
I'm envisioning that there could be a text file at the top level, say /usr/share/zoneinfo/version in typical layouts, containing "2021a" or the appropriate string. This'd make it a lot easier to diagnose what you've got in a particular installation.
$ cat /usr/share/zoneinfo/+VERSION 2021a
Interesting ... and in fact, Apple's labeling it in another way too, because I see this on my Mac laptop:
$ ls -l /usr/share/zoneinfo/ lrwxr-xr-x 1 root wheel 38 Sep 13 19:15 /usr/share/zoneinfo/ -> /var/db/timezone/tz/2021a.1.0/zoneinfo
But that pretty much just begs the point, which is that there's no *standard* cross-platform way to get this info. On my RHEL workstation, I don't see any identification info except the first line of tzdata.zi, which isn't a standard inclusion either. (Of course, I can consult the RPM package database to find out the version of the tzdata package ... still more platform dependency.)
My point isn't whether it's possible to figure this out on any given platform, but that tzdata itself ought to define a standard way to find it out. And I do not agree with Paul's opinion that "include tzdata.zi" is a good enough answer; lots of platforms won't care to expend the disk space to do it that way.
(But, in view of Apple having already done it like that, maybe there's something to be said for using +VERSION as the file name.)
regards, tom lane
One odd possibility on standardizing access to version information: a zic'd line such as... Zone Version 0 - 2021c ...would allow use of the command... TZ=Version date ...to discover the version.-) @dashdashado On Thu, Oct 7, 2021 at 1:01 PM Tom Lane via tz <tz@iana.org> wrote:
Philip Paeps via tz <tz@iana.org> writes:
This is looking terribly fragmented. Spare a thought for a hypothetical engineer tasked with debugging a Java application on Debian with some Python scripts on Fedora talking to a PostgreSQL database running on FreeBSD...
BTW, that brings a thought to mind: why isn't there an easy way to identify the release version of an installed tzdata tree?
I'm envisioning that there could be a text file at the top level, say /usr/share/zoneinfo/version in typical layouts, containing "2021a" or the appropriate string. This'd make it a lot easier to diagnose what you've got in a particular installation.
Some vendors (Red Hat at least) include the tzdata.zi file in /usr/share/zoneinfo. I persuaded Paul awhile back to put a version comment at the top of that, so that provides a way to determine the version if your vendor did that. But it seems like a mighty redundant approach.
regards, tom lane
On 10/7/21 13:41, Arthur David Olson via tz wrote:
One odd possibility on standardizing access to version information: a zic'd line such as... Zone Version 0 - 2021c ...would allow use of the command... TZ=Version date ...to discover the version.-)
Clever! I hadn't thought of that. This could supplant the "# version" line in tzdata.zi, and I suppose a similar trick could be used for the "# redo", "# ddeps", and "# dataform" lines - though this would limit us to ASCII alphanumerics and '-' and '+' in version numbers, which could be a bit restrictive.
Paul Eggert via tz <tz@iana.org> writes:
On 10/7/21 13:41, Arthur David Olson via tz wrote:
One odd possibility on standardizing access to version information: a zic'd line such as... Zone Version 0 - 2021c ...would allow use of the command... TZ=Version date ...to discover the version.-)
Clever! I hadn't thought of that. This could supplant the "# version" line in tzdata.zi, and I suppose a similar trick could be used for the "# redo", "# ddeps", and "# dataform" lines - though this would limit us to ASCII alphanumerics and '-' and '+' in version numbers, which could be a bit restrictive.
Yeah, that's a cute idea. I like it a bit better than my proposal, because it offers the possibility of checking the TZ version through APIs that don't necessarily offer direct access to the zoneinfo file tree (mumble Postgres mumble). regards, tom lane
Paul Eggert via tz <tz@iana.org> writes:
On 10/7/21 13:41, Arthur David Olson via tz wrote:
One odd possibility on standardizing access to version information: a zic'd line such as... Zone Version 0 - 2021c
Clever! I hadn't thought of that. This could supplant the "# version" line in tzdata.zi,
BTW, I'd still advocate for keeping the "# version" comment. It seems likely that people have already built software or processes that rely on that, and it's not like removing it would save anything noticeable. regards, tom lane
On 10/6/21 9:26 PM, Philip Paeps via tz wrote:
This is looking terribly fragmented.
Fragmented yes, terrible no. This sort of disagreement is reasonably common, as distros are understandably cautious about taking upstream patches. This was true even before the recent disagreement. End users should not assume "if I keep my installations of distro X and distro Y up-to-date, they'll agree about every timestamp no matter how obscure". That's not true now, and it's never been true. It's not even true for different releases of the same distro, even if both releases are being maintained.
participants (11)
-
Alan Mintz -
Arthur David Olson -
Clive D.W. Feather -
Deborah Goldsmith -
Guy Harris -
Paul Eggert -
Paul Ganssle -
Philip Paeps -
Russ Allbery -
Steven R. Loomis -
Tom Lane