Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel
== Current IANA time zone database situation == ftp://ftp.iana.org/tz/data/zone.tab contains one zone for ISO country code "IL" named Asia/Jerusalem. IL decodes to ISRAEL http://www.iso.org/iso/home/standards/country_codes/iso-3166-1_decoding_tabl... == Problem == Jerusalem is internationally not recognized as part of Israel. Using Jerusalem as reference location for Israel in the IANA time zone database may thus violate UN resolutions. == Solution == ftp://ftp.iana.org/tz/code/Theory reads "Use the most populous among locations in a country's time zone", this seems to be Tel Aviv. That would mean using Asia/Tel_Aviv. == Information on the status of Jerusalem == No UN member has an embassy in Jerusalem says: http://en.wikipedia.org/wiki/Positions_on_Jerusalem There is no UN LOCODE for Jerusalem in the IL-file: http://www.unece.org/fileadmin/DAM/cefact/locode/il.htm The page http://www.un.org/Depts/dpi/palestine/ links to "The Status of Jerusalem" http://www.un.org/Depts/dpi/palestine/ch12.pdf The penultimate paragraph reads: "The General Assembly revisited the question of Jerusalem at its fifty-fifth session. In a resolution adopted on 1 December 2000, the Assembly determined that the decision of Israel to impose its laws, jurisdiction and administration on the Holy City of Jerusalem was illegal and, therefore, null and void. The Assembly also deplored the transfer by some States of their diplomatic missions to Jerusalem in violation of Security Council resolution 478 (1980)." The UN SC Resolution 478 can be found at http://www.un.org/documents/sc/res/1980/scres80.htm -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
Oh, brilliant effort! I admire the (dare I? I dare:) chutzpah to approach this topic head-on, which shows a pluck and verve not seen in the time zone community since, well, Astrolabe. I fear, however, that this level of trolling requires such nuance and skill, not to mention a good bench of sock puppets and an environment full of politically-charged people to rile, that it may not have been quite the right time or the right list. Athletes injure themselves by not taking enough rest after a big match; I would hate to see that happen here. For the time being, then, let's move on. While I am very much looking forward to the creative efforts we'll no doubt see when we hold the 4th Annual Zoneinfo Trolling Games next year, it's just too soon after the Macquarie Invitational for everyone to be in top form. -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Tobias Conradi Sent: Saturday 20 April 2013 08:21 To: tz@iana.org Subject: [tz] Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel
On Sat, Apr 20, 2013 at 5:14 PM, David Braverman <david@braverman.org> wrote:
Oh, brilliant effort!
Here is more about the Israel territorial history in the zone.tab: Looking at https://github.com/eggert/tz/commit/65a7988fe8b4007023ef2130064421eacd263e4c shows the oldest file having the Gaza Strip as part of Israel +IL +3146+03514 Asia/Jerusalem most locations +IL +3130+03428 Asia/Gaza Gaza Strip it says "Arthur David Olson authored 17 years ago" on the page (2013 - 17 = 1996) Looking at https://github.com/eggert/tz/commit/bd52a52309bafce0766bd8eb13bf6d7875ebd09b shows that Gaza is changed to country code "PS" it says "Arthur David Olson authored 15 years ago" on the page (2013 - 15 = 1998) So, after Gaza has been fixed, Jerusalem could be too. -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
Actually, I am not aware of any country that officially recognizes Jerusalem as part of Israel, except for Israel itself. For most countries, including the USA, the status of Jerusalem is on hold pending the completetion of a peace treaty, according to resolutions of the UN. The largest city in recognized Israel is Tel Aviv. On 2013-04-20 11:14, David Braverman wrote:
Oh, brilliant effort! I admire the (dare I? I dare:) chutzpah to approach this topic head-on, which shows a pluck and verve not seen in the time zone community since, well, Astrolabe.
I fear, however, that this level of trolling requires such nuance and skill, not to mention a good bench of sock puppets and an environment full of politically-charged people to rile, that it may not have been quite the right time or the right list. Athletes injure themselves by not taking enough rest after a big match; I would hate to see that happen here.
For the time being, then, let's move on. While I am very much looking forward to the creative efforts we'll no doubt see when we hold the 4th Annual Zoneinfo Trolling Games next year, it's just too soon after the Macquarie Invitational for everyone to be in top form.
-----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Tobias Conradi Sent: Saturday 20 April 2013 08:21 To: tz@iana.org Subject: [tz] Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel
--
On Sat, Apr 20, 2013 at 2:21 PM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
That would mean using Asia/Tel_Aviv.
Shouldn't it be Asia/תֵּל־אָבִיב? I think we should finally start supporting UTF8. Until the name can be expressed properly in the local language, I don't think we should make any change. Kevin -- Kevin Lyda Galway, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
On Sat, Apr 20, 2013 at 6:34 PM, Kevin Lyda <kevin@ie.suberic.net> wrote:
On Sat, Apr 20, 2013 at 2:21 PM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
That would mean using Asia/Tel_Aviv.
Shouldn't it be Asia/תֵּל־אָבִיב? Not according to: ftp://ftp.iana.org/tz/code/Theory Use only valid POSIX file name components (i.e., the parts of names other than `/'). Within a file name component, use only ASCII letters, `.', `-' and `_'.
I don't think we should make any change. Why that?
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Sat, Apr 20, 2013 at 6:21 PM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Sat, Apr 20, 2013 at 6:34 PM, Kevin Lyda <kevin@ie.suberic.net> wrote:
Shouldn't it be Asia/تل أبيب? Not according to: ftp://ftp.iana.org/tz/code/Theory Use only valid POSIX file name components (i.e., the parts of names other than `/'). Within a file name component, use only ASCII letters, `.', `-' and `_'.
And you just accept that? Why shouldn't the Arabic name be used - is this further European injustice against the peaceful Palestinian people?
I don't think we should make any change. Why that?
Why did you partially quote me and then ask me a question that the part you deleted answered. My full sentence was, "Until the name can be expressed properly in the local language, I don't think we should make any change." Is this because you realise that I have exposed your pro-Israel bias? Kevin -- Kevin Lyda Galway, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
On Sun, Apr 21, 2013 at 12:29 AM, Kevin Lyda <kevin@ie.suberic.net> wrote:
On Sat, Apr 20, 2013 at 6:21 PM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Sat, Apr 20, 2013 at 6:34 PM, Kevin Lyda <kevin@ie.suberic.net> wrote:
Shouldn't it be Asia/تل أبيب? Your are lying, you wrote: http://mm.icann.org/pipermail/tz/2013-April/019138.html
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
Kevin Lyda <kevin@ie.suberic.net> wrote: |And you just accept that? Why shouldn't the Arabic name be used - is |this further European injustice against the peaceful Palestinian |people? There is still life behind the wall? That is good news! --steffen
On Sat, May 4, 2013 at 9:51 PM, <Paul_Koning@dell.com> wrote:
Can we please stop this silly stuff? I'm getting tired of putting tz mailing list senders on my spam list.
Indeed. Any time we're breaking into stuff like this ... On Sat, Apr 20, 2013 at 6:29 PM, Kevin Lyda <kevin@ie.suberic.net> wrote:
On Sat, Apr 20, 2013 at 6:21 PM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Sat, Apr 20, 2013 at 6:34 PM, Kevin Lyda <kevin@ie.suberic.net> wrote:
Shouldn't it be Asia/تل أبيب? Not according to: ftp://ftp.iana.org/tz/code/Theory Use only valid POSIX file name components (i.e., the parts of names other than `/'). Within a file name component, use only ASCII letters, `.', `-' and `_'. And you just accept that? Why shouldn't the Arabic name be used - is this further European injustice against the peaceful Palestinian people? I don't think we should make any change. Why that? Why did you partially quote me and then ask me a question that the part you deleted answered. My full sentence was, "Until the name can be expressed properly in the local language, I don't think we should make any change." Is this because you realise that I have exposed your pro-Israel bias?
It doesn't matter if it's serious or tongue-in-cheek, it's not useful at all. Yes, beyond just inconsiderations that start all the way back with ARPANET, ANSI and other legacy details, we all live in the "real world." And yes, we can all also debate the history, issues, injustices, etc... of the world, and make many, many subjective arguments in many directions. But despite how little or much we do, all in the name of awareness and understanding, all we're going to do is end up with the exact same, technical issues. For the most part, the overwhelming majority of people here are not insensitive, but also do not have an agenda other than a technical one, because, simply, it's as objective as we can be, even if imperfect, even if not everyone has the same experiences, even if not everyone is aware of every detail. Just try to remain focused on the technical issues and try to come up with solutions that are as considerate as possible while still feasible given how the project has always operated, for impartiality as best as it can. -- bjs
Follow up to "Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel" http://mm.icann.org/pipermail/tz/2013-April/019134.html ----------- http://www.bbc.co.uk/news/world-middle-east-22395494 <citation> Google spokesman Nathan Tyler said: "We're changing the name 'Palestinian Territories' to 'Palestine' across our products. We consult a number of sources and authorities when naming countries. "In this case, we are following the lead of the UN, Icann [the Internet Corporation for Assigned Names and Numbers], ISO [International Organisation for Standardisation] and other international organisations." </citation> That is not a territorial issue, but it also shows that usage of terminology related to Israel/Palestina by UN, ICANN, ISO and "other international organisation" may play a role for other entities. What is the reason that the IANA time zone database keeps Jerusalem as Israel territory as introduced by Arthur David Olson around 1996? (https://github.com/eggert/tz/commit/65a7988fe8b4007023ef2130064421eacd263e4c) -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Sat, May 4, 2013 at 6:44 PM, Bennett Todd <bet@rahul.net> wrote:
What is the reason that the IANA time zone database keeps Jerusalem as Israel territory
Because change is expensive. I am will to produce the patch file for free.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Sat, May 4, 2013 at 7:22 PM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
On Sat, May 4, 2013 at 6:44 PM, Bennett Todd <bet@rahul.net> wrote:
What is the reason that the IANA time zone database keeps Jerusalem as Israel territory
Because change is expensive. I am will to produce the patch file for free. Fix my typo: I am willing to produce the patch file for free.
-- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
On Sat, May 4, 2013 at 10:23 AM, Tobias Conradi <mail.2012@tobiasconradi.com
wrote:
Fix my typo: I am willing to produce the patch file for free
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. -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2013.0118 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
On Sat, May 4, 2013 at 7:37 PM, Jonathan Leffler <jonathan.leffler@gmail.com> wrote:
On Sat, May 4, 2013 at 10:23 AM, Tobias Conradi <mail.2012@tobiasconradi.com> wrote:
Fix my typo: I am willing to produce the patch file for free
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.
The word cosmetic is not found in: ftp://ftp.iana.org/tz/code/Theory Can you generate a more solid reply, based on tzid name changes over the last 10 years (Practice) and official documentation and policies (Theory)? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
Creating the patch is easy and cheap. Doing anything more active than smiling at it and ignoring it, that's expensive.
On Sat, May 4, 2013 at 7:42 PM, Bennett Todd <bet@rahul.net> wrote:
Creating the patch is easy and cheap.
Doing anything more active than smiling at it and ignoring it, that's expensive.
How do you define "more active"? For me creating a patch is "more active than smiling at it and ignoring it", but as said, I would do that. Why is fixing this bug considered "expensive" by you, while many other bugs are fixed? -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com
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.
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@iana.org [mailto:tz-bounces@iana.org] On Behalf Of random832@fastmail.us Sent: 07 May 2013 16:48 To: tz@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.
On 2013-05-07 16:47, random832@fastmail.us wrote:
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.
Would there be any problems changing the country code for Asia/Jerusalem to, say, "XJ" in zone.tab, adding an entry for "XJ" to iso3166.tab and adding an entry for Asia/Tel_Aviv with country code "IL" to zone.tab? -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
<<On Tue, 7 May 2013 18:02:35 +0100, Ian Abbott <abbotti@mev.co.uk> said:
Would there be any problems changing the country code for Asia/Jerusalem to, say, "XJ" in zone.tab, adding an entry for "XJ" to iso3166.tab and adding an entry for Asia/Tel_Aviv with country code "IL" to zone.tab?
Yes. Some (many?) implementations use their own table of ISO 3166 codes, which includes only the codes on ISO 3166-MA's list. -GAWollman
On Tue, May 07, 2013 at 11:47:32AM -0400, random832@fastmail.us wrote:
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
Hmm - is there any official explanation of what zone.tab actually is, apart from the comments inside? It simply lists timezones in use in a specific country, nothing more, nothing less. And timezone identifiers are just identifiers with a minimum of meaning. The timezone database doesn't define what political boundary each timezone falls in. It defines what time zones are in use within political boundaries. Yes, at least one timezone exists for any region, by definition, as long as that region actually has a physical location, as the timezone identifiers are meant to (roughly) identify the largest city within a region (where region is not defined by political boundaries). I really don't understand why people are so obsessed with making the timezone database a political instrument. It shouldn't be.
political pressure. But that ignores the fact that the database is taking a political position _now_, by mentioning a disputed territory in zone.tab.
No, the timezone database does no such thing. It's people who want to change this situation who are politically motivated. It's simple to see: tell me why to change anything here _without_ a political reason. All proponents of change are politically motivated. And so far, it seems all of them use a political interpretation of e.g. zone.tab, when zone.tab itself says no such thing. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schmorp@schmorp.de -=====/_/_//_/\_,_/ /_/\_\
On Tue, May 7, 2013, at 16:01, Marc Lehmann wrote:
Yes, at least one timezone exists for any region, by definition, as long as that region actually has a physical location, as the timezone identifiers are meant to (roughly) identify the largest city within a region (where region is not defined by political boundaries).
This is where you are mistaken. The regions are _absolutely_ defined by political boundaries. It's why we have separate regions for Norway, Denmark, and Sweden, instead of one for all of them; it's why we have a separate region for that little bit of Germany that follows Switzerland's timezone (Europe/Busingen), instead of simply drawing a single region around it and Europe/Zurich.
On Tue, 07 May 2013, random832@fastmail.us wrote:
At the risk of annoying people by continuing this discussion, I'm confused what the supposed cost of this change actually is.
I had not noticed, until your message, that there was already an Asia/Tel_Aviv zone, so I had incorrectly assumed that changing the representative city for Israel would be more costly. I suspect that some of the objections were derived from a similar misunderstanding.
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.
Given that there's a dispute about whether or not the city of Jerusalem is in the country of Israel, I think it would be sensible to avoid using Jerusalem as the representative city for Israel's timezone. Given that there is already an Asia/Tel_Aviv zone, with identical data to the Asia/Jerusalem zone (implemented via a "Link" directive in the input data), and that there is no dispute about whether or not Tel Aviv is in Israel, and that Tel Aviv is the largest city in the undisputed part of Israel, I think it would be reasonable to use Tel Aviv as the representative city for Israel's timezone. Accordingly, I suggest: * Reverse the direction of the link, making Asia/Tel_Aviv the primary name and making Asia/Jerusalem a link to it. * Use Asia/Tel_Aviv instead of Asia/Jerusalem in zone.tab. --apb (Alan Barrett)
Perfect. I fully agree. On 2013-05-08 4:52, Alan Barrett wrote:
On Tue, 07 May 2013, random832@fastmail.us wrote:
At the risk of annoying people by continuing this discussion, I'm confused what the supposed cost of this change actually is.
I had not noticed, until your message, that there was already an Asia/Tel_Aviv zone, so I had incorrectly assumed that changing the representative city for Israel would be more costly. I suspect that some of the objections were derived from a similar misunderstanding.
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.
Given that there's a dispute about whether or not the city of Jerusalem is in the country of Israel, I think it would be sensible to avoid using Jerusalem as the representative city for Israel's timezone.
Given that there is already an Asia/Tel_Aviv zone, with identical data to the Asia/Jerusalem zone (implemented via a "Link" directive in the input data), and that there is no dispute about whether or not Tel Aviv is in Israel, and that Tel Aviv is the largest city in the undisputed part of Israel, I think it would be reasonable to use Tel Aviv as the representative city for Israel's timezone.
Accordingly, I suggest:
* Reverse the direction of the link, making Asia/Tel_Aviv the primary name and making Asia/Jerusalem a link to it.
* Use Asia/Tel_Aviv instead of Asia/Jerusalem in zone.tab.
--apb (Alan Barrett)
--
So is cow-towing to an aparteid state. The unilateral declaration of Jerusalem as capital of Israel is in violation of international law and custom. On 2013-05-04 12:44, Bennett Todd wrote:
What is the reason that the IANA time zone database keeps Jerusalem as Israel territory
Because change is expensive.
--
Where in the TZ database is Jerusalem declared the capital of Israel? Deborah Goldsmith On May 4, 2013, at 10:53 AM, David Patte ₯ <dpatte@relativedata.com> wrote:
So is cow-towing to an aparteid state.
The unilateral declaration of Jerusalem as capital of Israel is in violation of international law and custom.
On 2013-05-04 12:44, Bennett Todd wrote:
What is the reason that the IANA time zone database keeps Jerusalem as Israel territory
Because change is expensive.
--
The tz database does not tell Jerusalem is the capital of Israel. However, at least, zone.tab specifies TZ Asia/Jerusalem belongs to country specified by code IL, that is Israel. IL +3146+03514 Asia/Jerusalem I actually consulted with a development group in Middle-East in my company several years ago, when I was working on the short time zone IDs in CLDR/Unicode locale extension project based on UN LOCODE. (Of course, UN does not assign any LOCODE to Jerusalem) Our development team in Middle-East said - "Time in Jerusalem" is perfectly fine - but "Time in Jerusalem (Israel)" has a political problem and not acceptable by some regions. The display name in the software (CLDR/ICU) was constructed from a localized name of a city and a country, and the country for each zone was resolved by data imported from zone.tab. So I told them about the specific line in zone.tab. At that time, they said it's really problematic and they told me they were going to post something in this mailing list. (Although, I did not see any at that time) I think Toby's point was to use a different city "Tel Aviv" - so zone.tab can be changed to: IL +xxxx+yyyy Asia/Tel_Aviv "Asia/Jerusalem" is just a zone identifier. This might be similar to "Asia/Shanghai" vs. "Asia/Beijing" discussion. If the way of display a zone is problematic, then it should be resolved by the code formatting the zone name. But the tz database maintainer may still consider this because the tz database can stay away from the political conflict. -Yoshito
Where in the TZ database is Jerusalem declared the capital of Israel?
Deborah Goldsmith
On May 4, 2013, at 10:53 AM, David Patte ₯ <dpatte@relativedata.com>
wrote:
So is cow-towing to an aparteid state.
The unilateral declaration of Jerusalem as capital of Israel is in violation of international law and custom.
On 2013-05-04 12:44, Bennett Todd wrote:
What is the reason that the IANA time zone database keeps Jerusalem
as
Israel territory
Because change is expensive.
On May 6, 2013, at 3:01 PM, <yoshito_umaoka@us.ibm.com> <yoshito_umaoka@us.ibm.com> wrote:
..."Asia/Jerusalem" is just a zone identifier. This might be similar to "Asia/Shanghai" vs. "Asia/Beijing" discussion. If the way of display a zone is problematic, then it should be resolved by the code formatting the zone name.
Exactly. The presentation of time zone choices is a user interface design choice, entirely outside the scope of the TZ project.
But the tz database maintainer may still consider this because the tz database can stay away from the political conflict.
NO! The TZ process is NOT a political process. I strongly object to any of these attempts to make it so. There are a whole lot of political issues in the world. This one is merely one of them, perhaps better known than some others for reasons I will not discuss here (because I'm writing in a technical forum, not a political one). But if we get suckered into making changes for this one, we may next get into a debate about the Falkland Islands, Taiwan, or any number of other places that some politicians disagree about. Again, I do not want any part of that sort of nonsense. It has no place in a technical group such as the TZ project. paul
This issue is very different than the Falklands, Taiwan, or Tibet, or Quebec or Texas for that matter. The SIGNIFICANT difference here is that world bodies that are mandated to decide on such political issues have ALREADY come to a decision on this - Jerusalem is not part of Israel, Israel's declaration is 'null and void'. And since that time, no country recognizes Jerusalem as part of Israel. Perhaps, because of your distate for politics, you may have missed that point. Listing Jerusalem as part of Israel has ALREADY been rejected by everyone; save Israel and the tz database. By leaving the database as is, the tz database is, inadvertantly or not, making a political statement - an extreme one, and one contrary to world concensus. On 2013-05-06 15:22, Paul_Koning@dell.com wrote:
NO! The TZ process is NOT a political process. I strongly object to any of these attempts to make it so.
There are a whole lot of political issues in the world. This one is merely one of them, perhaps better known than some others for reasons I will not discuss here (because I'm writing in a technical forum, not a political one). But if we get suckered into making changes for this one, we may next get into a debate about the Falkland Islands, Taiwan, or any number of other places that some politicians disagree about.
Again, I do not want any part of that sort of nonsense. It has no place in a technical group such as the TZ project.
paul
--
I don't think it's relevant what the rest of the world thinks. If everyone in Jerusalem agrees on one reality, and everyone outside Jerusalem agrees on a different reality, then it would be logical to go with the reality that is agreed upon by those in Jerusalem. It matters what time people in Jerusalem think it is, what time their clocks show, not what time people at the UN or Washington DC think it should be. If the people in Jerusalem can't agree on the time, that is one thing, but it would seem that what people outside of Jerusalem think is totally irrelevant to this discussion. During WWII, Hitler imposed German time on the land he conquered. Japan did the same in Asia. If this happened today and the UN condemned these acts of aggression and declared them illegal, should we then ignore the realities on the ground and continue to insist on the "original" time zones, even if they aren't being used any more in practice? Aaron On Tue, May 7, 2013 at 11:50 AM, David Patte ₯ <dpatte@relativedata.com> wrote:
This issue is very different than the Falklands, Taiwan, or Tibet, or Quebec or Texas for that matter. The SIGNIFICANT difference here is that world bodies that are mandated to decide on such political issues have ALREADY come to a decision on this - Jerusalem is not part of Israel, Israel's declaration is 'null and void'. And since that time, no country recognizes Jerusalem as part of Israel.
Perhaps, because of your distate for politics, you may have missed that point. Listing Jerusalem as part of Israel has ALREADY been rejected by everyone; save Israel and the tz database.
By leaving the database as is, the tz database is, inadvertantly or not, making a political statement - an extreme one, and one contrary to world concensus.
On 2013-05-06 15:22, Paul_Koning@dell.com wrote:
NO! The TZ process is NOT a political process. I strongly object to any of these attempts to make it so.
There are a whole lot of political issues in the world. This one is merely one of them, perhaps better known than some others for reasons I will not discuss here (because I'm writing in a technical forum, not a political one). But if we get suckered into making changes for this one, we may next get into a debate about the Falkland Islands, Taiwan, or any number of other places that some politicians disagree about.
Again, I do not want any part of that sort of nonsense. It has no place in a technical group such as the TZ project.
paul
--
On Tue, May 7, 2013, at 16:37, Aaron Brown wrote:
I don't think it's relevant what the rest of the world thinks. If everyone in Jerusalem agrees on one reality, and everyone outside Jerusalem agrees on a different reality, then it would be logical to go with the reality that is agreed upon by those in Jerusalem. It matters what time people in Jerusalem think it is, what time their clocks show,
Nobody is talking about changing the time definition for Asia/Jerusalem. This argument is whether a line with "IL" in the first column and "Asia/Jerusalem" in the third column ought to appear in zone.tab. Nothing more, nothing less.
On May 7, 2013, at 5:00 PM, <random832@fastmail.us> wrote:
On Tue, May 7, 2013, at 16:37, Aaron Brown wrote:
I don't think it's relevant what the rest of the world thinks. If everyone in Jerusalem agrees on one reality, and everyone outside Jerusalem agrees on a different reality, then it would be logical to go with the reality that is agreed upon by those in Jerusalem. It matters what time people in Jerusalem think it is, what time their clocks show,
Nobody is talking about changing the time definition for Asia/Jerusalem.
This argument is whether a line with "IL" in the first column and "Asia/Jerusalem" in the third column ought to appear in zone.tab. Nothing more, nothing less.
Ok then, should Asia/Taipei be listed with country code CN? Or not at all? It seems to me the exact same reasoning that is being used here applies to both cases. In fact, such a proposal is not being made. This tells me that the motivation for the current proposal is in fact not what its proponents are pretending it is. paul, speaking only for himself and for no other person or organization.
Reading this and the Macquarie Island discussion, the frequent repeated requests for renaming of TZs etc, is there a case for having a readily accessible set of documents that define current practice on TZs? In the years I've been following the group, these issues seem to be coming up with increasing frequency. Instead of relying on a pool of common knowledge underlying the existing documents, and having to exp[lain and justify things each time when challenged, things would be properly defined. This would also then provide a fixed starting point for looking at any changes to the current practice. Tim Smartcom Software Ltd Portsmouth Technopole Kingston Crescent Portsmouth PO2 8FA United Kingdom www.smartcomsoftware.com Smartcom Software is a limited company registered in England and Wales, registered number 05641521. -----Original Message----- From: tz-bounces@iana.org [mailto:tz-bounces@iana.org] On Behalf Of Paul Koning Sent: 08 May 2013 01:42 To: random832@fastmail.us Cc: tz@iana.org Subject: Re: [tz] Proposal to use Asia/Tel_Aviv for Israel - Jerusalem is not internationally recognized as part of Israel On May 7, 2013, at 5:00 PM, <random832@fastmail.us> wrote:
On Tue, May 7, 2013, at 16:37, Aaron Brown wrote:
I don't think it's relevant what the rest of the world thinks. If everyone in Jerusalem agrees on one reality, and everyone outside Jerusalem agrees on a different reality, then it would be logical to go with the reality that is agreed upon by those in Jerusalem. It matters what time people in Jerusalem think it is, what time their clocks show,
Nobody is talking about changing the time definition for Asia/Jerusalem.
This argument is whether a line with "IL" in the first column and "Asia/Jerusalem" in the third column ought to appear in zone.tab. Nothing more, nothing less.
Ok then, should Asia/Taipei be listed with country code CN? Or not at all? It seems to me the exact same reasoning that is being used here applies to both cases. In fact, such a proposal is not being made. This tells me that the motivation for the current proposal is in fact not what its proponents are pretending it is. paul, speaking only for himself and for no other person or organization.
On 2013-05-08 01:42, Paul Koning wrote:
On May 7, 2013, at 5:00 PM, <random832@fastmail.us> wrote:
On Tue, May 7, 2013, at 16:37, Aaron Brown wrote:
I don't think it's relevant what the rest of the world thinks. If everyone in Jerusalem agrees on one reality, and everyone outside Jerusalem agrees on a different reality, then it would be logical to go with the reality that is agreed upon by those in Jerusalem. It matters what time people in Jerusalem think it is, what time their clocks show,
Nobody is talking about changing the time definition for Asia/Jerusalem.
This argument is whether a line with "IL" in the first column and "Asia/Jerusalem" in the third column ought to appear in zone.tab. Nothing more, nothing less.
Ok then, should Asia/Taipei be listed with country code CN? Or not atall? It seems to me the exact same reasoning that is being used here applies to both cases.
I don't know why Asia/Taipei isn't listed under country code TW.
In fact, such a proposal is not being made. This tells me that the motivation for the current proposal is in fact not what its proponents are pretending it is.
I think it's more about reducing confusion, although there are arguments for and against maintaining the status quo. On the one hand, residents of Israel need a city to represent their timezone, and to them, Jerusalem seems the obvious choice. On the other hand, a sizeable minority of the citizens of Jerusalem (especially a sizeable minority(?) of the residents of East Jerusalem) probably don't acknowledge themselves as Israeli citizens and might rather follow Palestinian timezone rules, or perhaps switch between Israeli and Palestinian timezone rules on a daily basis, depending on transportation timetables, work requirements, religious congregational requirements, local TV schedules, opening times of local businesses, etc. I admit I have no very little knowledge of the actual situation on the ground in the affected regions and only threw country code XJ into the pot as a suggestion for further discussion.
paul, speaking only for himself and for no other person or organization.
Ditto. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
On Tue, May 7, 2013 at 8:42 PM, Paul Koning <paulkoning@comcast.net> wrote:
Ok then, should Asia/Taipei be listed with country code CN? Or not at all?
It seems to me the exact same reasoning that is being used here applies to
both cases.
Just to "piggy-back" on Paul's "case" here, let's look at this as a process-oriented detail ... Whenever one makes a suggestion for a change, _please_ also: A) State how it effects _more_ than just one (1) case -- aim for at least three (3) -- keep sigma in mind here B) Put down explicit sets of logic, that are completely objective and technical, and run all three-plus (3+) cases through it C) Evaluate if and how this will effect not only existing Zoneinfo history and approach, but what impacts it may have to code/files I think people here are _failing_ to recognize that this isn't about one (1) case, and it has multiple impacts to many other cases. So ... if there is a strong case to make a change in not just logic, but how Zoneinfo does things and goes forward in doing things -- including possible changes to Zoneinfo code and/or formats (hopefully not, but at least assumptions) -- then make it, and make it objectively doing A-B-C together. Just my $0.02, not speaking on-behalf of anyone else. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
On 07/05/13 21:37, Aaron Brown wrote:
I don't think it's relevant what the rest of the world thinks. If everyone in Jerusalem agrees on one reality, and everyone outside Jerusalem agrees on a different reality, then it would be logical to go with the reality that is agreed upon by those in Jerusalem. It matters what time people in Jerusalem think it is, what time their clocks show, not what time people at the UN or Washington DC think it should be. If the people in Jerusalem can't agree on the time, that is one thing, but it would seem that what people outside of Jerusalem think is totally irrelevant to this discussion.
No one here is dictating what time the people of Jerusalem should think. AFAIK, the people of Jerusalem use two different sets of time zone rules. Whatever is done, Asia/Jerusalem will remain in the tz database for backwards compatibility. The main argument is the country code it should be listed under. -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Please do not mess with the id's, it's always a hassle one way or another. Create your own patches for your own systems if you like, it's all right and does not take my time. On Tue, 7 May 2013, David Patte wrote:
to a decision on this - Jerusalem is not part of Israel, Israel's declaration
Parts of Jerusalem have been in Jordan and are currently disputed, but most of it has been Israel continously from the start, I see no problem with that. -- Jaakko
Can we please stop this silly stuff? I'm getting tired of putting tz mailing list senders on my spam list. paul On May 4, 2013, at 1:53 PM, David Patte ₯ wrote:
So is cow-towing to an aparteid state.
The unilateral declaration of Jerusalem as capital of Israel is in violation of international law and custom.
On 2013-05-04 12:44, Bennett Todd wrote:
What is the reason that the IANA time zone database keeps Jerusalem as Israel territory
Because change is expensive.
--
participants (21)
-
Aaron Brown -
Alan Barrett -
Bennett Todd -
Bryan J Smith -
David Braverman -
David Patte ₯ -
Deborah Goldsmith -
Garrett Wollman -
Ian Abbott -
Jaakko Hyvätti -
Jonathan Leffler -
Kevin Lyda -
Marc Lehmann -
Paul Koning -
Paul_Koning@Dell.com -
random832@fastmail.us -
Steffen Daode Nurpmeso -
Tim Thornton -
Tobias Conradi -
Wallace, Malcolm -
yoshito_umaoka@us.ibm.com