The geographic extent of legislative time zones can change, they can morph, split and merge, and also appear and vanish completely. In consequence, the only way to unambiguously specify which local time results when adding durations backwards and forwards in time, without being constrained to limited periods of legislative non-change, is to fix a specific geographical location, and to specify how local time has changed and is changing at that particular location. That is what the tz database does. In principle, you could define a separate time zone for each point on Earth, but that isn’t practical. So the compromise is to pick representative cities.

One important thing to understand is that the time zones of the tz database, and hence generally the time zones used in computing, are a slightly different concept than legislative time zones.

▲

kstrauser 3 days ago | parent [-]

I get all that, I really do. And I know America/LA is a reasonable pick: it’s a large, well known city nearby that’s always going to be at the same time I am when I’m at home.

Still feels weird, though. What if LA specifically passes a time zone law so that now it’s sometimes wrong for everyone else in California. Do we add an America/Cali_except_LA zone?

That’s probably hypothetical. It seems unlikely. But what a major pain in the ass if it did happen?

▲

layer8 2 days ago | parent | next [-]

Another city would be picked to represent the rest of California, and the point is that using that city as a time zone ID would then work not only for future times, but also backwards for any times in the past. If, instead, you had America/California, or US/Pacific, those would be ambiguous either forward or backwards in time.

So the trade-off is timezones being specific to a particular city but remaining unambiguous forward and backward in time.

You can’t avoid pain when there is a change in the geographic area of a legislative time zone. But you can avoid the case of a time zone ID becoming ambiguous in terms of the UTC<—>local time mapping it’s supposed to define. The latter is the aim of the present scheme.

▲

arcfour 3 days ago | parent | prev [-]

That can happen and has. And the result is basically as you described it.

Yes, it's silly and inefficient, but so are time zones. It's not an easy problem to wrangle on a computer, for reasons that are exactly as you have described.

	▲	kstrauser 3 days ago \| parent [-]
		Yeah, it’s easy enough to pick at edge cases, but it’s amazing we have something that generally works this well at all. I don’t know if I have any better ideas, at least ones that the smart people maintaining the DB haven’t already considered and rejected. It’s an inherently complex, ugly mess.