On 2020-10-25 01:55, heba.hamad@mtit.gov.ps wrote:

.I’m Heba Hamad .I have been appointed as a focal point by the Ministry of telecommunication and information technology (state of Palestine) to communicate with you

I’m contacting you in regard to the time zone data base the field related to the state of Palestine. I checked the published data regarding the time zones related to Palestine and noticed that it’s not accurate, and hence I would like to ask for an update to the time zone data base related to Palestine to be as follow

*  PS   State of Palestine  _Asia/AlQuds_       UTC +2:00 *

I'm a poster to this list with no official position. Asia/Jerusalem is the time zone identifier (all are English) for what is called in Arabic (transliterated to English) al-Quds https://en.wikipedia.org/wiki/Jerusalem, which shows it currently observing gmtoff 7200 UTC+0200: $ zdump Asia/Jerusalem Asia/Jerusalem Thu Mar 26 23:59:59 2020 UT = Fri Mar 27 01:59:59 2020 IST isdst=0 gmtoff=7200 Asia/Jerusalem Fri Mar 27 00:00:00 2020 UT = Fri Mar 27 03:00:00 2020 IDT isdst=1 gmtoff=10800 Asia/Jerusalem Sat Oct 24 22:59:59 2020 UT = Sun Oct 25 01:59:59 2020 IDT isdst=1 gmtoff=10800 Asia/Jerusalem Sat Oct 24 23:00:00 2020 UT = Sun Oct 25 01:00:00 2020 IST isdst=0 gmtoff=7200 If the information is not up to date, please contact your system or software provider. Also please consider the (lack of adequate lead time in any) notice given by politicians and bureaucrats, and the weeks and months it takes for changes to be published here, then pass through organizations' own bureacratic quality assurance/quality control, testing, publishing, deployment, and distribution processes. Sometimes this goes through many stages as in mobile phones: to the software vendor e.g. Google, Huawei, Apple, etc.; then to the handset vendor e.g Samsung, Apple, Huawei, etc.; then to the mobile telephone companies in each region, which send the updates to each vendors handsets on their networks. Any of these may decide that they don't have enough sales in recent years in that region to bother putting any priority on a prompt change, and wait for another that affects more of their recent customers. Arabic/Palestinian software is free to label that English time zone identifier using e.g. Unicode/ICU/CLDR mappings: http://site.icu-project.org/design/formatting/timezone/getdisplayname and where that mapping is not done, that is an indavisable and regrettable omission by the software project or software developer (see "theory" below). If you wish the list to consider changes to a time zone, please read previous posts to the list about the zone in question, the comments with the data in the file containing the zone in question, and https://data.iana.org/time-zones/theory.html to understand the scope, principles, and *pragmatics* followed. Please provide links to official government documents on official government web sites, or links to respected primary or secondary sources which provide detailed information about practices in effect in a zone, or quotations and citations for them from widely available respected primary or secondary published sources, preferably in English. And as complained about in many posts on this list by all major software vendors, please provide a year or at least many months notice of any proposed changes, to allow changes to be officially published here, then be downloaded and passed through downstream companies and organizations [Please note that this list provides technical information according to the situation in effect on the ground in a territory, and avoids all political situations and stances. The alternatives are to omit providing any information for disputed zones or locations, which helps no-one in those zones using compuerized information systems, or to relabel all zones with some numerically derived identifiers, forcing all participants to look up mappings to perform any interpretation, greatly reducing any possible participation to those with the capability of comprehending those mappings, and could only be accomplished over a transition time of years to allow downstream consumers time to upgrade their systems to handle the mappings.] -- 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.]