London is on Berlin time?
London is on Berlin time?
Posted Oct 2, 2021 20:41 UTC (Sat) by Wol (subscriber, #4433)In reply to: London is on Berlin time? by NYKevin
Parent article: A fork for the time-zone database?
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,
Wol
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?
* 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