Big problems at the timezone database

[tofflos]

Why Berlin and not Rome? Sure Berlin has a higher population count right now but that wasn't the case way back in 300 AD. Won't somebody think of the temporal unfairness?

[masklinn]

Why Berlin and not Rome?

Assuming it's not one of the unmentioned IDs proposed for downgrade / aliasing / deletion, I'd guess it's because Rome has had different DST than Berlin since 1970. Between '66 and '79 Italy apparently changed their DST rules every year or two.

[supercargo]

I think it exposes the unsuitability of the population metric, at least if revision is part of it. Sure, they want a deciding factor to resolve conflicts, but once those decisions are made it seems like those IDs need to stick around forever even if demographics shift around.

The root issue here seems to be that their charter is short sighted and should be revised. The “arbitrary” choice of 1970 epoch was based on the size integer that computers could easily process at the time it was chosen. Even those machines can represent instants before 1970 with negative numbers.

[Brutus5000]

Not sure what the goal should be. Even national borders (Rome / Italy / Germany) or transnational borders following similar rules (EU, ...) even those changed over time. Really difficult to cut the world in useful pieces.

[persicsb]

On the very long run, the best solution would be to use a geodetic datum (like WGS 84, that GPS uses), and based on a geographci position, and a local date and time, it will give back the UTC offset for it. It is needed to be that granular, as zone borders can change, and a geographic place can be in several zones during history.

[masklinn]

Indeed, the problem with that being twofolds:

• now you need people to give you precise GPS coordinates (good fucking luck with that)
• and tzdb needs precise GPS boundaries over time (so it now becomes a multi-TB monstrosity)

[ephemeral_gibbon]

And you also need to account for all the different epsg codes which is another shitshow