How often are the tzdata packages in Ubuntu updated? Surprisingly, every few months.
Not sure if you can congratulate this particular member of the lucky 10,000 for learning that timezones and DST rules change constantly worldwide.
The TZ mailing list has of course been on top of the BC time zone change and is doing its best to coordinate with other entities to ensure chaos doesn't ensue.
I mean, one time changes seem like the simplest cases for them.
Especially with several months lead time.
In Israel, for some time (until 2013), the introduction day for summer time was decided every year and was subject to political power haggling.
Circa 2011 I remember the transitional government of egypt going back and forth several time on DST, and only taking a final decision a week or two before. In 2016 they cancelled DST three days before it was slated to start.
Russia decided to stay on summer time with (I believe) 6 weeks notice.
Turkey wanted to delay DST for one week because of national exams.
Morocco has DST except during Ramadan. I think that legally, Morocco follows the traditional Muslim method of determining the first day of Ramadan, which involves physically observing the new Moon, while other majority Muslim countries trust in almanacs instead. This of course makes it even harder to determine DST rules for Morocco.
I think this is somewhat naïve. Several months of lead time is true only if the change is analyzed as permanent DST. The BC announcement was written like they thought they were being reasonable with several months of lead time, but instead of defining permanent DST, they appeared to have defined a surprise change to standard time, so the tzdb was initially going to ship it as such, which would have been a problem.
Also, if you do permanent DST, you really need to be committed not to introduce DST on top of that later.
See my other comment with links about both these points.
Haha, that's amazing, I didn't know that. I do know a similar situation existed in Jordan, when the day for DST change was subject to royal approval, and the King presumably had a lot of other stuff to worry about. So the date was generally decided late.
Pet theory: the less politicians can do in the "real" world, due to treaties, international trade etc., the more they feel the need to mess with DST.
Alberta has done the TZdb a favor by legally designating their new timezone as "Alberta Time". A big issue with British Columbia was that they're designating their new timezone as "Pacific Time", which is ambiguous.
Another case of what counts as “standard time” what counts as “daylight-saving time”: In the 1940s the UK first decided to stay on DST year round and then decided to do DST on top of that, which now results in data modeling issues. I understand that there was a war and people try stuff when things get dire, but, still, 1) imagine planning on doing something that you’d call British Double Summer Time and not stopping thinking that maybe don’t do that and 2) that the political entity that owns the reference point for the offset zero wanted to do an offset of two hours shows how bogus it is to get attached to the clock showing particular numbers and then trying to fiddle with when particular numbers are shown. https://unicode-org.atlassian.net/browse/CLDR-19382
I wonder how many residents of B.C. have lazily selected a West Coast US city as their location with regards to timezones, and will be caught out when the province doesn't move back to standard time in November.
But I guess you'd choose "America/Vancouver" to get localized date formats, etc. (I have never been to Canada so don't know the specific differences)
PagerDuty doesn't have America/Vancouver as an option for some reason. I used to use America/Los_Angeles, but I've now switched to America/Phoenix, as they too are permanently on UTC-7.
Anglo Canadian date formats are the same as in the US, I believe, but francophone Canadians use a different method.
You just reminded me at getting very mad at some linux installer with a timezone selection map that was too small and so I just clicked anywhere in central Europe but then it auto-adjusted the language based on the timezone (and I didn't notice) and so I could enjoy a random language after a reboot :D
Good stuff. I'd personally not thought about it far enough to realize that you the UTC timestamp would be different if the timezone changes (or rather doesn't) in the future.
gerikson | a day ago
Not sure if you can congratulate this particular member of the lucky 10,000 for learning that timezones and DST rules change constantly worldwide.
The TZ mailing list has of course been on top of the BC time zone change and is doing its best to coordinate with other entities to ensure chaos doesn't ensue.
Example https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/VX2Z3CBO6KHTYZNBBKFFWM7ZCI6TVCXP/
And via that same list, Alberta is considering staying on permanent summer time too.
Edit better link
skade | a day ago
I mean, one time changes seem like the simplest cases for them.
In Israel, for some time (until 2013), the introduction day for summer time was decided every year and was subject to political power haggling.
https://en.wikipedia.org/wiki/Israel_Summer_Time
masklinn | a day ago
Especially with several months lead time.
Circa 2011 I remember the transitional government of egypt going back and forth several time on DST, and only taking a final decision a week or two before. In 2016 they cancelled DST three days before it was slated to start.
gerikson | a day ago
Russia decided to stay on summer time with (I believe) 6 weeks notice.
Turkey wanted to delay DST for one week because of national exams.
Morocco has DST except during Ramadan. I think that legally, Morocco follows the traditional Muslim method of determining the first day of Ramadan, which involves physically observing the new Moon, while other majority Muslim countries trust in almanacs instead. This of course makes it even harder to determine DST rules for Morocco.
hsivonen | 17 hours ago
I think this is somewhat naïve. Several months of lead time is true only if the change is analyzed as permanent DST. The BC announcement was written like they thought they were being reasonable with several months of lead time, but instead of defining permanent DST, they appeared to have defined a surprise change to standard time, so the tzdb was initially going to ship it as such, which would have been a problem.
Also, if you do permanent DST, you really need to be committed not to introduce DST on top of that later.
See my other comment with links about both these points.
gerikson | a day ago
Haha, that's amazing, I didn't know that. I do know a similar situation existed in Jordan, when the day for DST change was subject to royal approval, and the King presumably had a lot of other stuff to worry about. So the date was generally decided late.
Pet theory: the less politicians can do in the "real" world, due to treaties, international trade etc., the more they feel the need to mess with DST.
fengshaun | 6 hours ago
Alberta just passed the Official Time Act (https://www.alberta.ca/albertas-new-time-system), so no more clock changes.
gerikson | 2 hours ago
Alberta has done the TZdb a favor by legally designating their new timezone as "Alberta Time". A big issue with British Columbia was that they're designating their new timezone as "Pacific Time", which is ambiguous.
hsivonen | 18 hours ago
Regarding potential chaos, this thread is more interesting: https://lists.iana.org/hyperkitty/list/tz@iana.org/thread/IEZR4HYQXZTUMGRA7FEZJAKAOGFGOPIP/
Another case of what counts as “standard time” what counts as “daylight-saving time”: In the 1940s the UK first decided to stay on DST year round and then decided to do DST on top of that, which now results in data modeling issues. I understand that there was a war and people try stuff when things get dire, but, still, 1) imagine planning on doing something that you’d call British Double Summer Time and not stopping thinking that maybe don’t do that and 2) that the political entity that owns the reference point for the offset zero wanted to do an offset of two hours shows how bogus it is to get attached to the clock showing particular numbers and then trying to fiddle with when particular numbers are shown. https://unicode-org.atlassian.net/browse/CLDR-19382
gerikson | a day ago
I wonder how many residents of B.C. have lazily selected a West Coast US city as their location with regards to timezones, and will be caught out when the province doesn't move back to standard time in November.
But I guess you'd choose "America/Vancouver" to get localized date formats, etc. (I have never been to Canada so don't know the specific differences)
novedevo | 23 hours ago
PagerDuty doesn't have America/Vancouver as an option for some reason. I used to use America/Los_Angeles, but I've now switched to America/Phoenix, as they too are permanently on UTC-7.
Anglo Canadian date formats are the same as in the US, I believe, but francophone Canadians use a different method.
wink | 13 hours ago
You just reminded me at getting very mad at some linux installer with a timezone selection map that was too small and so I just clicked anywhere in central Europe but then it auto-adjusted the language based on the timezone (and I didn't notice) and so I could enjoy a random language after a reboot :D
oneirine | a day ago
As I like to say, "Programmers deal with time zones so you don't have to"
JulianSildenLanglo | a day ago
Good stuff. I'd personally not thought about it far enough to realize that you the UTC timestamp would be different if the timezone changes (or rather doesn't) in the future.