Zefram/Paul, Thanks for your further comments. 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. Regards, Daniel