London is on Berlin time?
London is on Berlin time?
Posted Sep 30, 2021 17:30 UTC (Thu) by Wol (subscriber, #4433)In reply to: London is on Berlin time? by NYKevin
Parent article: A fork for the time-zone database?
As said elsewhere, what do the LOCALS think? And if they can't decide, provide both.
I believe the ISO system is pragmatic, just use that - hence EU, UK, various other country codes ...
Cheers,
Wol
Posted Sep 30, 2021 17:41 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (17 responses)
Also, UK is not an ISO country code. The code for the United Kingdom is GB. The .uk TLD was allocated by IANA as a favor to the UK (mostly because they had already been using it before the ccTLD system existed). ISO had nothing to do with that.
Posted Sep 30, 2021 21:45 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (16 responses)
Who is actually in charge of the tzdb? ISO? IANA?
(And yes I know all about UK not being an ISO code. After all, it's the suffix on my email address! And I know all about Ukraine wanting UK as their ISO code until they discovered it was blocked ... I had a Ukrainian girlfriend for a while.)
Cheers,
Posted Oct 1, 2021 1:06 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (15 responses)
I may have mixed up IANA and ICANN (one of them does IP addresses and the other does domain names, and I can never keep them straight in my head), but essentially yes. EU and UK are both "exceptionally reserved" by ISO to avoid confusion, but are not considered ISO codes. The DNS people made exceptions for both of them, in part because they were already reserved on the ISO side, and in part because they didn't really have a good reason to say "no."
Also of note: ISO assigns codes to several jurisdictions which nobody thinks of as a "country," such as Puerto Rico (there is an active movement for US statehood, but nobody seriously claims that Puerto Rico is independent of the US, either de facto or de jure). Oddly, this includes Antarctica, which isn't really a "jurisdiction" at all (there is no permanent, continent-wide governing authority, and the authority of governments to enforce laws within their respective territorial claims is limited by the terms of the Antarctic Treaty System). In practice, Antarctica uses UTC regardless of longitude, so we can arguably just ignore it, but it is on the list.
The ISO standard does include a flag which indicates whether the UN considers each jurisdiction to be "independent" or not, so you can just ignore the non-independent ones if you like. Taiwan, as you might expect, is flagged as non-independent, because that's the official position of the UN. ISO does not provide any other means of distinguishing between "a country" and "not a country," so if you want to call Taiwan a country and Antarctica (or Puerto Rico) not a country, you have to come up with your own list instead of using ISO's list.
> And again, what happens with historical data? I don't know when ISO_3166 was started, but Austro-Hungary probably never had a ISO code, but could possibly have had summer time.
Which is yet another reason to avoid using ISO codes and just use Continent/City, as tzdb does. Europe/Vienna still exists today. A hypothetical ISO-based Austria-Hungary timezone, however, would've had to be migrated at some point, as ISO has a policy of releasing codes once they are no longer used. Such codes are reserved for quite a long time in most cases, but can eventually be reassigned to another country. OTOH, they reassigned RU from the USSR to the Russian Federation rather quickly, because the latter is recognized as the successor state of the former. This would have broken the timezones of various former Soviet Republics, if using an ISO-based timezone scheme.
(I have no idea what the timezone of Austria-Hungary was, but Wikipedia says that DST was actually invented in Germany and Austria-Hungary, at least at a national scope, anyway. So yes, they did have DST rules.)
> Who is actually in charge of the tzdb? ISO? IANA?
tzdb is nominally "organized" by ICANN, but in practice I believe it operates much like a standard FOSS project.
Posted Oct 1, 2021 17:12 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (14 responses)
Not for the political entity that defines what the timezone is!
GMT/BST is defined by the UK government. Portugal, and South Africa, while both lying on the Prime Meridian, use different time zones, Portugal I believe is on CET, South Africa I don't have a clue.
Continent/City should be used to SELECT which time zone(s) apply. From my point of view, I couldn't care whether it's UK/Greenwich, England/London, Scotland/Edinbugh or what. That would contain a link to a timezone of GB-GMT.
But, to pick on a country I've mentioned, When did Portugal switch from local (GMT) to CET time? Portugal/Lisbon should NOT return the time zone data for Berlin because at some time in the not so distant past it was different.
So if the user selects Portugal/Lisbon, it should say something like "1970-present EU-CET, pre-1970 PT-PST" (for poruguese standard time or whatever they called it before they went on to CET.
At the end of the day, location and time zone are two completely different things, and SHOULD NOT be referred to by the same identifier.
Cheers,
Posted Oct 1, 2021 18:06 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link]
No part of the Portuguese mainland lies on or east of the Prime Meridian, and large parts of it lie west of 7.5°W.
No part of the South African mainland is less than 15°E of the Prime Meridian. Cape Town, which isn't quite the westernmost point but is certainly the westernmost major city, is 18°E. Johannesburg and Pretoria are 28°E, Pietermaritzburg is 30°E, Durban is 31°E, and South African Standard Time, used nationwide, is entirely sensibly UTC+0200 year-round (there is no DST in South Africa).
> When did Portugal switch from local (GMT) to CET time?
Portugal is currently, and was historically, on WET (UTC+0000 / +0100).
Between 1966-76 and 1992-1996, Portugal was on CET (UTC+0100 winter time).
And in Lisbon (9°W), the mean solar azimuth at 12:00 standard time / 13:00 DST over the course of the year tells you that you should be on UTC-0100 / +0000 if using one-hour-aligned time zones.
Posted Oct 2, 2021 20:08 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (12 responses)
Posted Oct 2, 2021 20:24 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
More to the point, it does NOT work for Europe. Timezones and political jurisdictions do NOT align, so don't use the same key to reference both. Likewise, it doesn't work for the US. Just because multiple US states. and multiple EU countries have *chosen* to share a time zone, doesn't mean things won't change. There is a lot of talk about Britain going on to CET/CEST, but the Scots in particular are extremely unhappy about that.
If the TIMEZONE is independent from the POLITICAL, then if England/London decides to change while Scotland/Edinburgh doesn't, then separating timezone from location makes the change dead simple. If the timezone is called Britain/London, it's a lot more involved.
Cheers,
Posted Oct 2, 2021 20:41 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (10 responses)
Data Integrity?
After all, isn't the big complaint about this change that it is CORRUPTING HISTORICAL DATA.
Rule One of data integrity, Do Not Store Unrelated Data In The Same Table. If you mix time data and location data (as is being pushed here) you are doing exactly that!
You store your timezones in one table, and you store your locations in a separate table. Then you have a link that contains location, dates, and timezones, that says which timezone applies where and when. At which point your database is robust and resistant to political screw-ups.
Unlike the present mess where the maintainer is wilfully trashing the historical information, and setting the system up for a major mess if countries decide to shift timezones - as indeed the UK has been talking about doing ...
(I'm a database guy. I dislike relational because it insists you splat data referring to one object across multiple tables, which causes loads of trouble. But the opposite also holds - plonking data referring to multiple objects in one table causes just as much if not more trouble!)
Cheers,
Posted Oct 3, 2021 4:51 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (9 responses)
* A UTC offset is a (possibly fractional) signed number, usually written as e.g. UTC+5 (or whatever number you want).
tzdb does not mix those two types of object up. It is very clearly structured as mapping timezones to UTC offsets (or more specifically, to lists of offsets along with the dates and times when those offsets went into effect). Therefore, I can only surmise that you are talking about yet another type of object, which is not listed above, but I simply cannot visualize such an object as relevant to the problem at hand.
The whole point of tzdb is that you pick e.g. Europe/Berlin, or Europe/Paris, or America/New_York, or whatever you fancy, and then it tracks the local time in that city indefinitely into the future, regardless of geopolitical upheaval. It is very deliberately jurisdiction-agnostic. Imagine, for a moment, that tzdb was around before World War I. Then Europe/Vienna would have tracked Austro-Hungarian law on DST etc., and everyone in the Vienna metropolitan area would be following the Europe/Vienna timezone. Similarly, everyone in the Budapest metro area would be following Europe/Budapest, which would also track Austro-Hungarian law. After the war, Austria-Hungary ceased to exist, and therefore Europe/Vienna would have transparently updated to follow Austrian law, and Europe/Budapest would have transparently updated to follow Hungarian law.
Under your proposal, everyone would need to go into their settings and switch from the no-longer-existent Austria-Hungary to the Austrian jurisdiction or Hungarian jurisdiction explicitly. Or else some piece of software would have to figure out whether the user is now Austrian or now Hungarian, and update the settings without telling the user, and we would have to hope it got it right. But under the tzdb system, everything Just Works™ because the timezones were never tied to jurisdictions in the first place.
In short: You are proposing the addition of a third type of data, and I still don't understand what that type is intended to accomplish, in terms of solving a real-world problem that is not already solved by the existing system. It's fine to talk about normalization, but this schema is already normalized.
Posted Oct 3, 2021 7:07 UTC (Sun)
by smurf (subscriber, #17840)
[Link] (7 responses)
Yeah, that is/was the idea. The whole brouhaha we're discussing here originates in the brain-dead (IMHO) idea that right now Europe/Stockholm and Europe/Berlin are the same, and Berlin is larger than Stockholm, so the tzdb maintainer feels free to alias the former to the latter – regardless of the fact that this is not historically correct. Plus, if Stockholm ever decides to diverge from Berlin's rules in the future, a rather inconveniently large number of Swedes will need to update their tzdb and then manually fix their timezone settings.
Posted Oct 3, 2021 18:47 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
Now let's throw in the FACT that - even right now - Berlin does not have the authority to decide what timezone Stockholm follows, and aliasing Berlin to Stockholm is just plain stupid.
Okay. Let's (for the sake of convenience/accuracy/whatever) call our base timezones "Meridian0" or "Meridian150W" or "Meridian900E" etc. (I've multiplied latitude by 10 so it makes half-hour zones easier - go back to 1800 or so and Bristol would have been "Meridian75W" by that standard...)
Then we have the POLITICAL AUTHORITY that sets summer time - probably the EU that says "Summertime starts last Sunday in March, ends last Sunday in October, at 0100 Meridian150W" - lets call those rules EU-EST.
And lastly we have Sweden/Stockholm that says "base meridian is Meridian150W, Daylight saving is EU-EST, applies 1970 onwards" or whatever.
Then if a country decides to change timezone, eg the UK shifts to European time, we just change Britain/London to say Meridian0 until 2024, Meridian150W from 2025, EU-EST applies from 1970 onwards".
As smurf says, the idiocy is in keying a bunch of TIMEZONE data on a city LOCATION. Which fucks up any other cities that just happen at present to be in the same time zone. Imagine what grief it's going to cause if Britain DOES go onto CET/CEST and tzdb changes our timezone to Berlin ... (or rather, changes Berlin time to London!!!)
Cheers,
Posted Oct 3, 2021 19:10 UTC (Sun)
by amacater (subscriber, #790)
[Link]
Posted Oct 3, 2021 19:50 UTC (Sun)
by jrn (subscriber, #64214)
[Link] (4 responses)
I agree about needing to update tzdb (this is a fact of life in all jurisdictions, since we cannot predict the future), but why would they need to update their settings instead of continuing to use Stockholm like they were already doing? It's not like this tzdata update makes "TZ=Europe/Stockholm" stop working.
Posted Oct 3, 2021 22:36 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (2 responses)
Because this change means that the real Stockholm will be deleted and lost.
Which means that the historical data used for Stockholm will actually be the data for Berlin (which may, or may not, be the same).
Cheers,
Posted Oct 4, 2021 18:40 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
Posted Oct 4, 2021 22:28 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
Right now, two minutes with zdump should make it obvious that they're emphatically not the same.
Posted Oct 4, 2021 18:47 UTC (Mon)
by smurf (subscriber, #17840)
[Link]
And since neither Eggbert nor anybody else can predict whether that alias holds in the future, adding such an alias is Just Plain Wrong.
Posted Oct 4, 2021 12:30 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
The problem, timezones are NOT jurisdiction-agnostic.
LOCAL (ie solar) time is jurisdiction-agnostic. But it's the politicians who decide what timezone applies to the country as a whole. They might like to think their jurisdiction extends to the sun, but I think I know who (or what) would win THAT battle :-)
Cheers,
London is on Berlin time?
London is on Berlin time?
Wol
London is on Berlin time?
London is on Berlin time?
Wol
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
Wol
London is on Berlin time?
Wol
London is on Berlin time?
* A timezone is a set of rules for deciding which offset to use. tzdb uses names such as Europe/Berlin for them, but there are a variety of other names you could use instead (CET/CEST, "Central European Time", etc.).
London is on Berlin time?
London is on Berlin time?
Wol
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
Wol
London is on Berlin time?
London is on Berlin time?
Which means that the historical data used for Stockholm will actually be the data for Berlin (which may, or may not, be the same).
London is on Berlin time?
London is on Berlin time?
Wol