Dear Mr. Robert, All your comments will be taken into consideration and sent to our Standards Preparation Committee for review Best Respects, Sent from Mail for Windows From: Robert Elz Sent: Wednesday, January 5, 2022 2:03 AM To: heba.hamad@mtit.gov.ps Cc: tz@iana.org; asheed hanoon; laith.daraghmeh@mtit.gov.ps Subject: Re: [tz] The State of Palestine has adopted the first part of the specification for its time zone Most of your concerns have been addressed by others, but I noticed in reading your document, in section 7, in the two examples on page 8, you have "Australia Western Standard Time" listed as a standard time which does not vary within a year (in Example 1) and Australian Central Standard Time listed as one which does vary within a year (in Example 2). I'm not exactly sure of the point of those examples, and it is certainly true that "standard time" can be said to be the local time as specified at any point during the year. If you meant that Western Australia does not observe summer time, whereas South Australia does, then that would be fine - but that does not seem likely as an interpretation, as you have US Eastern in Example 1, and summer time (daylight saving) is certainly used there (you even have USEST and USEDT both listed there). Otherwise, if "standard time" is intended to represent the "natural" offset from UTC (your definition in section 6 is not clear which of those meanings is intended) then Australian Central Standard Time varies no more or less than Australia Western Standard Time does. In summer, in South Australia, but not the Northern Territory, Australian Central Summer Time applies (which is the standard time by the earlier definition here). Or more correctly, just Central Standard Time and Central Summer Time - adding "Australian" as a prefix isn't really necessary in Australia, and is not in any legislation I have ever seen. Perhaps because the abbreviation is ACST (or just CST) in both cases leads to some confusion here - but as Paul Eggert said in his reply, those abbreviations are largely meaningless (many single timezone areas don't bother to name the time, as anything other than the time - there is no need to distinguish it from any other time within the jurisdiction, and with no name for the time, have no abbreviation either). I am not sure why Palestine feels the need to label its time - it is unlikely it will ever span sufficient degrees of longitude to need more than one zone, and actually separately labeling standard vs summer time tend to cause more problems than it solves - there should be just "the time", that its offset from UTC varies during the year isn't relevant to that, 16:00 is 16:00, whether than happens to be 14:00 UTC or 13:00 UTC (or something different). Also as Paul hinted, the major factor in achieving: Palestine in particular will be able to reduce systems downtime, human effort and last-minute arrangements that is caused by not having a unified time zone and also not being able to have a clear road map for setting daylight saving time as well as providing certainty that the given information is relevant to the State of Palestine country of ownership. (quoted from your Introduction - page 5) is to publish changes long in advance of when they are to take effect. It can take a very long time for systems to be updated to new rules (some are designed without that capacity at all, unfortunately) - authorities that expect a change notified a month (or less) in advance of its effective date are more or less guaranteeing disruption, and (perhaps) system down time. Making changes very infrequently, and always with lots of notice -- Paul suggested a year, I'd advocate even more than that. This applies not only to a change to be made, but to a planned change being abandoned as well - that also needs just as much advance notification as the original change needed, as updates will otherwise already have started being distributed with the earlier announced change included - a whole new set of updates is required to reverse that. One last comment here - the time zone database *always* reflects the time that the people of the region actually use in their day to day lives. What authority sets that time is not our concern, and your ability to influence what goes into the time zone data base is limited entirely by your ability to influence the times that the people (railways, busses, radio and TV, airlines, schools, banks, ...) all use. As long as you set those times, the times you set (whether reported to us by you, or someone else) will be what the time zone data base contains. If it turns out that at some future time someone else is deciding what the local clocks should indicate, then it will be their time offsets and change dates in the database, not yours. None of this is any different for Palestine than anywhere else in the world. kre