On 2018-02-20 17:30:53 (-0500), Garrett Wollman wrote:
On Tue, 20 Feb 2018 16:36:55 -0500, John Hawkinson <jhawk@MIT.EDU> said:
Paul.Koning@dell.com <Paul.Koning@dell.com> wrote on Tue, 20 Feb 2018:
I would not recommend that. "backward" exists, as the name suggests, only for backward compatibility with old naming conventions.
I'm not sure we've made such a statement of deprecation. I think a lot of people use the US/* style, even though it's not what the tz db prefers. I think a lot of people would be up-in-arms if those identifiers were deprecated anytime in foreseeable life of the project (measured in decades). But perhaps I am wrong (or too conservative).
When I was the timezone maintainer for FreeBSD, I made a deliberate decision not to use the backward file (unless the user rebuilt their system after changing a make variable). I believe the current maintainer has continued this policy
I suppose that by the "you touched it last so now you own it" principle, the current maintainer is me. I am indeed continuing your policy. FreeBSD doesn't use the tzdb build process directly (we have our own Makefile) and we only install the current zones.
so there's at least one downstream platform that does not support the old names and has not done so for about two decades. The zone.tab file (which FreeBSD's timezone chooser uses) does not reference the "backward" zones as I recall.
Correct. I have been thinking about using zone1970.tab instead (which we do not currently even install) but I haven't gotten around to it yet. (I also have some work in progress to bring tzcode up to a more recent version but ... turns out "time" is not only difficult to describe but also difficult to find!) Philip -- Philip Paeps Senior Reality Engineer Ministry of Information