Always install backward compatibility timezones, as they are installed on all major Linux distributions as well as NetBSD and OpenBSD.
Details
Details
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
lgtm!
| share/zoneinfo/Makefile | ||
|---|---|---|
| 74 ↗ | (On Diff #70239) | Why not merge this into the above list? |
| share/zoneinfo/Makefile | ||
|---|---|---|
| 47 ↗ | (On Diff #70239) | Should keep warning about using OLDTIMEZONES? How old is this warning? |
| share/zoneinfo/Makefile | ||
|---|---|---|
| 47 ↗ | (On Diff #70239) | Probably not because the option is removed (if it's undefined, the files are still installed). I think the intention of the warning was that OLDTIMEZONES would be removed one day (it's not going to be removed, as everybody else seems to be installing them and I also checked macOS). |
| 74 ↗ | (On Diff #70239) | Originally it was because they shall be separated from the "main" ones as these are compatibility subdirectories, but I think you do have a good point that line 73 (blank line) should be removed. Will fix. |
| share/zoneinfo/Makefile | ||
|---|---|---|
| 47 ↗ | (On Diff #70239) | The fact that this option is now a do nothing is exactly why we should warn about it's use, ie this review deprecates "OLDTIMEZONES" silently. |
Comment Actions
I think this change is a bad idea and should be reverted. (The "backward" file in the IANA db is for ancient compatibility, and FreeBSD has been excluding it by default since 1994 as far as I can tell; this is not the time to be adding it back.)
Comment Actions
To explain the full context of the original link:
PostgreSQL contains logic that tries to deduce the timezone name in use by scanning the zoneinfo directory looking for zones that behave exactly the same way that the OS-configured zone uses. Since there are a lot of aliases in the zoneinfo database, there are almost always multiple matches, and PostgreSQL picks according to a completely arbitrary rule: the shorter name is preferred, and for names of equal length, the alphabetically first name is preferred.
The consequence of this rule (which I personally believe is a bad one) is that if the backward-compatibility timezone names are present, it will in a large proportion of cases prefer a deprecated name over a current one. For example, "W-SU" will be preferred over "Europe/Moscow", in spite of being meaningless garbage now. The deprecated name will be preferred for over 25% of all canonical timezone names, including all major US timezones and a few European countries (GB, Eire, Portugal, Poland, Russia). Common examples include choosing "Navajo" over "America/Denver" for USA Mountain Time with DST.
This all should be considered a defect in PostgreSQL (and I say this as a PostgreSQL committer), not as something the OS should work around by including timezone entries for 120 random alias names that were all deprecated in 1993 or before.
Comment Actions
[...]
This all should be considered a defect in PostgreSQL (and I say this as a PostgreSQL committer), not as something the OS should work around by including timezone entries for 120 random alias names that were all deprecated in 1993 or before.
I tend to agree that it's a defect in PostgreSQL, but think that's a separate issue and does not mean we should remove these links.
In FreeBSD we encourage developers to consider POLA (Principle Of Least Astonishment) when making user-visible changes. The backward compatibility links are perfect examples of that principle, and evidently it's causing user pains today despite we have stopped shipping these links in rS2747 (September 1994), as the rest of world decided to not follow (checked NetBSD, OpenBSD, Debian, RedHat, macOS) and it's only giving users unnecessary headache. Plus, this is not only affecting PostgreSQL: a zone might have its name changed, and it doesn't seem to be doing good for user when an OS upgrade silently break existing code when it's trivially easy to avoid these.
Comment Actions
We already removed them. In 1994. What you're doing is adding them back, which is not a harmless change.
Plus, this is not only affecting PostgreSQL
Do you have a non-hypothetical example of this?
and it doesn't seem to be doing good for user when an OS upgrade silently break existing code
But that's not what's happening.
Comment Actions
Removing these backwards compatible timezones widely impacted Isilon OneFS end-users who were upgrading from one version to the next.
Prior to the work that I did in rS320702, my organization was modifying the zone info directly/creating old zones mappings, which was a painful change to carry forward. Making the backwards compatible zone mappings more accessible allowed us to avoid local changes in the base system.
It makes more sense to keep this inline with the upstream software project. It makes upgrades easier and new installs *should* be using the new timezone mappings, so the need for the old ones will die off over time. I would rather push for their removal in the zoneinfo project, instead of here.
Being the odd OS out already causes us enough pain. This change is sufficiently benign that I think we can proceed with what's been committed instead of second guessing the need for whether or not it should exist.
Comment Actions
So why is "W-SU" still there, referring to a political entity that hasn't even existed since 1991?
Comment Actions
I'm late to the party but for what it's worth: I support this change.
This was discussed on the tz mailing list in November last year.