[tz] Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel

[Wallace, Malcolm]

One technical point worth considering is that a goodly proportion of the clocks in Jerusalem do not show the time that the tz database would claim they do.  Given rough current estimates that the Arab population of (East) Jerusalem is upwards of 35%, and the likelihood that many of their clocks follow the Palestinian rules for DST rather than the Israeli rules, it seems awkward and inaccurate to use the name of the city for one set of rules but not the other.

Reference an earlier message on the topic:
     http://mm.icann.org/pipermail/tz/2011-September/008754.html

Regards,
    Malcolm

-----Original Message-----
From: tz-bounces at iana.org [mailto:tz-bounces at iana.org] On Behalf Of random832 at fastmail.us
Sent: 07 May 2013 16:48
To: tz at iana.org
Subject: Re: [tz] Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel

On Sat, May 4, 2013, at 13:37, Jonathan Leffler wrote:
> The cost isn't the cost of generating the patch file.  It's all the 
> other things that have to change that make it expensive.  Most of 
> those changes are not visible to the tz database; they are costs to 
> the consumers of the tx database.  The database changes when 
> necessary, not to be cosmetically more attractive.

At the risk of annoying people by continuing this discussion, I'm confused what the supposed cost of this change actually is. Both names already exist in the database, which makes it even less of a cost than renaming a timezone (and leaving an alias behind) usually has. The original change made in 1996 seems best described as "to be cosmetically more attractive" anyway, and doesn't seem to have caused any [technical] problems.

Unlike Mr. Conradi, I'm willing to assume the original change was based on a simple mistake rather than some malicious plot, but I don't see why there's such a big objection to changing it back.

High-minded arguments like the one made in http://mm.icann.org/pipermail/tz/1998-August/010224.html ignore the fact that A) the database explicitly identifies what political boundary each timezone falls within in zone.tab and B) even if not, the policy implicitly depends on this by requiring that at least one timezone exist per region (and per difference since 1970 within a region), despite (for
example) Europe/Oslo, Europe/Copenhagen, and Europe/Stockholm not having actually differed since 1970 - all having no DST between 1970 and 1980, and on EU after 1980. Actually, it's unclear to me why those shouldn't be aliases when (for example) Europe/Busingen is one. But I digress.

"This naming regime survived the demise of the Soviet Union without having to rename `Europe/Moscow' or `Asia/Tashkent'; it survived the recent revolution in the Congo without having to worry about its country-code change " - Yes, but zone.tab did have to change. Not in 1991, since it has only existed since 1996, but it did in fact change for the Zaire/Congo change.

The database itself wouldn't even have to change at all. There's no problem having a zone.tab line that names an alias - Europe/Busingen is one such example.

The only "cost" left is the perceived cost of being seen to give into political pressure. But that ignores the fact that the database is taking a political position _now_, by mentioning a disputed territory in zone.tab. And the fiction that the city names used as timezone identifiers aren't seen by humans is just that, a fiction.

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at http://www.standardchartered.com/en/incorporation-details.html.