Page MenuHomeFreeBSD

Always install backward compatibility timezones, as they are installed on all major Linux distributions as well as NetBSD and OpenBSD.
ClosedPublic

Authored by delphij on Apr 5 2020, 11:11 PM.

Details

Summary

Always install backward compatibility timezones, as they are installed on all major Linux distributions as well as NetBSD and OpenBSD.

Test Plan

Install FreeBSD and compare /usr/share/zoneinfo with other systems.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

delphij created this revision.Apr 5 2020, 11:11 PM
ngie accepted this revision.Apr 6 2020, 1:02 AM

Macro goatforit:

lgtm!

share/zoneinfo/Makefile
74 ↗(On Diff #70239)

Why not merge this into the above list?

This revision is now accepted and ready to land.Apr 6 2020, 1:02 AM
rgrimes accepted this revision.Apr 6 2020, 2:51 AM
rgrimes added inline comments.
share/zoneinfo/Makefile
47 ↗(On Diff #70239)

Should keep warning about using OLDTIMEZONES? How old is this warning?

delphij marked 2 inline comments as done.Apr 6 2020, 4:32 AM
delphij added inline comments.
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.

rgrimes added inline comments.Apr 6 2020, 5:08 AM
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.

This revision was automatically updated to reflect the committed changes.
delphij marked 2 inline comments as done.

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.)

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.

[...]

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.

does not mean we should remove these links.

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.

kevans added a subscriber: kevans.Apr 10 2020, 1:18 PM
ngie added a comment.EditedApr 10 2020, 7:05 PM

does not mean we should remove these links.

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?

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.

In D24306#535952, @ngie wrote:

new installs *should* be using the new timezone mappings, so the need for the old ones will die off over time.

So why is "W-SU" still there, referring to a political entity that hasn't even existed since 1991?

philip added a subscriber: philip.Apr 25 2020, 2:39 AM

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.