[tz] State of Palestine Time zone - need to update

[Brian Inglis]

On 2021-02-11 12:52, David Patte wrote:
> On 2021-02-11 14:06, Brian Inglis wrote:
>> On 2021-02-11 02:50, heba hamad wrote:
>>> In reference to your recent response at 25 Oct,2020 regarding State of 
>>> Palestine’s request to correct the ‘Time Zone Database’, we would like to 
>>> confirm that ‘TZ’ related to the State of Palestine is as follows:
>>>
>>> *_PS   State of Palestine   Asia/East Jerusalem       UTC +2:00_*
>>>
>>> Also, we would like to inform you that the State of Palestine comprises of 
>>> the West Bank, including East Jerusalem and Gaza, all of which are integral 
>>> parts of the State of Palestine, thus, as one territorial unit all areas 
>>> belong to the same time zone.
>>>
>>> We would like to also emphasize that East Jerusalem is an integral part of 
>>> the West Bank as stipulated under international law and by numerous 
>>> international resolutions.
>>>
>>> Therefore, we urge you to adopt the official name and correct your data base.
>>
>> IETF motto:
>> "We reject: kings, presidents, and voting.
>>  We believe in: rough consensus and running code."
>>
>> We provide pragmatic, useful information and care only what people's watches 
>> and systems are set to over a significant region and over a significant period 
>> of time.
>>
>> The territory mentioned is disputed but continues to fall under under the 
>> control of Israel which sets the time zones used on the ground.
>> The situation is similar in Crimea and elsewhere in the world.
>>
>> Anyone who wishes may set their systems to use Asia/Gaza, Asia/Hebron, or 
>> Asia/Jerusalem depending on the time they want to see.

> There seems to be a serious inconsistency between how Palestine is handled,
> and how Kiev is handled, and how Xinjiang is handled.
Each government gets to say what time should be used when by the residents in 
the territories they *control*, whether that is Russia, Ukraine, Israel, 
Palestine, Gaza, or Xinjiang Uyghur Autonomous Region.

> As I said, people on the ground in Gaza and Kiev and Xinjiang clearly care
> that their own systems are honoured, and clearly citizens there don't call
> themselves part of Israel's Palestinian Territories, Russia's colonies, nor
> China's.
What people's opinions are about what they wish is irrelevant: what matters is 
what the reality is in the region, and we reflect that, we don't decide that.
They might also wish we used the calendar they use, but we don't, and don't 
care, and won't change, even although the support and capability has been 
available for decades, and many rules would make more sense expressed in their 
native calendars.

> The current naming is clearly favouring the occupiers, over the actual users
> of that data.
It always favours what is used by those people who reside in the region, whether 
they have the government they would choose or not.
Many of us might also prefer to have different governments, or use different 
time zones than those in effect where we reside.
If you really dislike a time zone or a government, you will have to try to 
change it, or else move elsewhere, otherwise you will just have to put up with 
what you have.

The users of the data are the downstream systems using the project, and they are 
not pushing us to make any of these changes, they deal with their issues 
internally, and have to put up with the project making random unplanned changes, 
because of a few emails about spelling in a language not native to them, that 
would better be automoderated out of notice.

The naming is *meant* to be an internal identifier, and I personally hold the 
opinion that they should never be changed, until association or comprehension is 
misleading or negligible, as they are irrelevant outside of this project.

I see a lot of code in a lot of projects with crappy, insane, or even inverted 
identifiers, but I don't waste my time complaining about those usages, or 
submitting mass variable renaming patches.
I just hope that the contributors or maintainers will sensibly refactor those 
usages when sufficient maintenance is required, or confusion has been caused.

If downstreams or other sites expose or misuse those identifiers, the 
complainers should be told to complain about wherever they see them, as they 
chose to expose or misuse those identifiers.

Those downstreams, few of whom likely contribute to this project, rather it is 
the reverse where this project contributes freely to their business, as is our 
preference, nor do most acknowledge, nor care about this project, as the 
information is in the public domain, seem to do a better job of saying *NO* to 
complainers, who also have no vested interest in this project, do not make any 
contributions, and do not really care, except about petty political campaigns, 
to which they have been stirred up by ineffectual politicians, where the best 
they can do is provoke people to argue about spellings in a language they don't 
use, nor know much of.

Having caved to Ukraine, I would not be surprised to see more campaigns, to 
press for more politically motivated changes, that useless politicians can point 
to as accomplishments when nothing else is progressing.

That is why I am a verbose advocate of telling complainers to submit patches or 
PRs for consideration, fork the sources on github, patch the software they use 
to suit themselves, or *go pound sand*!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]