On 2017-10-16 19:58, Daniel Ford wrote:
I accept that DST 'rules' can be ephemeral, particularly in some locations. But I think the days of 'making a DST switch depend on actual eyeball observation of the new moon' are perhaps past, at least in most modern Muslim nations. These days they tend to accept the science of celestial motion, which predicts moon (or whatever) appearances at specified locations with great accuracy. You only have to Google 'ramadan 2018' (without the quotes) to convince yourself of this. If you know of other less predictable events that routinely cause changes to DST start/end dates, I'd be interested to hear about them.
Nevertheless, I understand that DST rules *do* change (and even timezones can change, though more rarely), so my intention is certainly to try to access the TZdb (or a derivative thereof) for my clock. But I would still prefer to download the current 'rule' rather than the current dates, so I can continue calculating the changeover events in the (unlikely) future absence of the TZdb.
In that unlikely event, my clock would continue using the most recent rule until the user's local authority decided to change the rule, at which time the user would have to manually enter the new rule into the clock. Hopefully this won't happen within a reasonable product lifetime!
I still have a lot of reading to do about the TZdb (thanks for the 'Theory' pointer, Paul), but when I've done that I'll almost certainly be back with a lot more questions. Than you all for your patience and tolerance.
Just look at the release history of a dozen or two releases per year, because governments changed time zone and daylight saving time with little notice. You should have been aware of Turkey making a change with zero notice last year. Some small countries, especially Caribbean nations, seem especially prone to give short notice annually. Someone from Sudan just posted they are changing their GMT offset at the start of next month. And people complain their mobiles and PCs don't show the correct time, when list members have to notice articles in the press, search for something like official confirmation, then the rule changes have to be made and posted on here, picked up by the mobile OS or PC distribution vendors, packaged, and made available for update; those updates then have to be picked up and installed by individuals or support staff; and in many cases pushed out across systems, or by mobile networks, to get to the end user's systems and applications. I suspect the long term solution may have to require Internet treaties with ICANN country members, and contracts with country code domain registrars, requiring their governments provide official advance notice of time zone and daylight saving time changes with at least 6 months notice to IANA, similar to their requirements to do so to IATA, to avoid air route, airport, facilities, and staff scheduling issues. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada