Comment by kstrauser
4 days ago
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?
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.
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.
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.