London is on Berlin time?
London is on Berlin time?
Posted Sep 30, 2021 15:38 UTC (Thu) by nim-nim (subscriber, #34454)In reply to: London is on Berlin time? by NYKevin
Parent article: A fork for the time-zone database?
There is an obvious good option – use country for countries that do not span multiple zones, and country/local-zone-name for the others.
Do not allocate a territory to some state that does not control it, do not invent zone names the locals do not use or understand, do not try to reform the whole planet to make it follow some kind of funky rule you invented before breakfast. If people in some part of the world can not agree on who owns what, alias both names and let them settle things by themselves.
All the funky rules you can invent will pour oil on the fire by favoring one party over another, just say no and leave politics to politicians, activists and other people that care nothing about time zones except as a pawn in some other game.
Posted Sep 30, 2021 16:48 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
> There is an obvious good option – use country for countries that do not span multiple zones, and country/local-zone-name for the others.
Exactly. Well, actually, call the time zone whatever the locals call it, prefixed by the 2-letter iso country designation (with exceptions for whatever the country code exceptions are) so we'd have UK-GMT, EU-CET, US-MST. (Along with UK-BST, RU-BST and US-BST ... :-)
Then each of the place links says which timezone is valid for what times.
Half the problem seems to be the maintainer's confusion as to the difference between a timezone, a place, and a political jurisdiction. You CANNOT store accurate data if you do not account for all three separately.
(And this seems to be why people are upset - that the data is being corrupted ...)
Cheers,
Posted Sep 30, 2021 16:55 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (32 responses)
Then you have to decide whether Kosovo, South Ossetia, Taiwan, etc. are "countries" or not. Also, according to https://en.wikipedia.org/wiki/List_of_states_with_limited..., at least one UN member does not recognize each of China (PRC), Israel, (South) Korea, (North) Korea, Cyprus, and Armenia, despite the fact that all of those countries are themselves UN members.
OTOH the "city" paradigm runs into Jerusalem (which may or may not have two timezones depending on who you ask, what religion they follow, how they feel about the one/two state solutions etc.). But that sort of dispute over individual cities seems to be much rarer than disputes over larger territories.
Posted Sep 30, 2021 17:30 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (18 responses)
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,
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,
Posted Sep 30, 2021 18:50 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (12 responses)
Thus, you *can* *not* wipe out those territories to please someone’s idea of political border even if you wanted to.
And then making both version of ownership exist at the same time is just a matter of aliasing as long as you’re smart enough to make all aliases point to a neutral key (for example a longitude+indice value) and not the name of someone else’s capital.
Posted Sep 30, 2021 20:34 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (11 responses)
This is why cities are (usually) superior to countries (except for Jerusalem, which is a whole other level of political-messed-upness).
> And then making both version of ownership exist at the same time is just a matter of aliasing as long as you’re smart enough to make all aliases point to a neutral key (for example a longitude+indice value) and not the name of someone else’s capital.
That breaks on Jerusalem just as much as calling it "Jerusalem" would. The problem is that the individual people living within the city go by different timezones depending on their nationality and the extent to which they personally recognize Israeli jurisdiction over the city. You can't lat/long your way out of that. If you try using numerical indices, then somebody has to be "first" and somebody has to be "second," and they'll argue over that instead.
Posted Oct 1, 2021 2:00 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link] (3 responses)
Posted Oct 1, 2021 6:59 UTC (Fri)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
Also, anybody can register a domain name. You have to have a more selective set of criteria than that. If you go by "does it have a ccTLD?" then you're right back to ISO country codes, but now they're wearing a funny hat.
Posted Oct 1, 2021 15:32 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link] (1 responses)
If they can afford to publish rules about their time zone then they can afford a few dollars a month for a domain name and some shared hosting capacity.
> Also, anybody can register a domain name.
Sure, and that's kind of the point. There should be some notability threshold for pulling the data into the collated time-zone database, just as a spam prevention measure, but I see no reason whatsoever to impose any further limits on who can publish time-zone information. If there are real people following the time zones some organization publishes then that organization's zones should be listed.
Posted Oct 10, 2021 0:40 UTC (Sun)
by flussence (guest, #85566)
[Link]
Posted Oct 1, 2021 8:19 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link] (5 responses)
The indice of the zone aliased to would be the same.
Because *operationally*, even if people disagree on who owns what, trains still have to leave on time, schoolchildren still have to go to school on time, so there is only one timezone in operation at any given time in a particular territory.
So the *correct* answer to cases like Taiwan is to have
Which is *exactly* the reverse of the TSDB move.
In real life you do not resolve arguments Salomons’ way with rash decisions everyone disagrees with (moreso when you *ability* to make fictitious grouping exist is nil). You resolve arguments by giving something to every party.
Especially in IT where aliases and indirections are the norm.
Posted Oct 2, 2021 20:02 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (4 responses)
This is incorrect. In Jerusalem, they *don't* agree on what the local time is (or, to be more precise, they don't agree on exactly when DST begins and ends). This *does* cause the exact disruptions you identify, and yet they disagree anyway. The same is also applicable to some of the western regions of China (because China insists on having one timezone for the whole country, despite the country being far too wide for this to make logical sense), where different communities are on different offsets and will informally indicate times as "local" or "Beijing" time (the "local" timezone doesn't officially exist, so it's not in tzdb, but people use it).
Posted Oct 2, 2021 22:36 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
AFAIU (based on podcast data), it actually differs based on the language being spoken (rather than being explicitly labeled as such). Speaking Chinese, time is Beijing-offset. Speaking the local language, time offsets are a more sensible offset.
Posted Oct 3, 2021 4:54 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
Posted Oct 3, 2021 8:48 UTC (Sun)
by ghane (guest, #1805)
[Link]
https://en.wikipedia.org/wiki/Xinjiang_Time
Posted Oct 4, 2021 13:35 UTC (Mon)
by nim-nim (subscriber, #34454)
[Link]
People can disagree on what zone the entity that schedules trains should use to display scheduling but this entity is most definitely knows what timezone it uses for scheduling decisions.
There is a strong temptation to roundtrip between physical location, timezone and political authority. That does not work. That will never work. It’s not a one-to-one relationship.
Labeling timezones with city names (and worse, country capital names) is horrible because it assumes this one-to-one relationship.
Posted Oct 3, 2021 18:45 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Wait... if they can agree on neither the time nor _the name of the city_ then there is no problem: just use those different names and problem solved! No?
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?
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
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
China/Taiwan and Taiwan exist at the same time in the database as aliases and point to a technical neutral key like 121.some_indice
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?
London is on Berlin time?