The way I understand it, Continent/City names aren't for pretty dropdowns or help texts (in fact, I'd wager they're kinda meh for that). They're the least bad way people have come up with to store and communicate timezones with future local dates, that doesn't require online geolocation. You're right that geolocation is the best. But offsets aren't a close second, like I feel your comments suggest - they're just a bad idea. To suggest that a timezone "is" an offset, while technically correct if you disregard future changes, is actively harmful to helping people write code with fewer timezone bugs.

Use IANA Continent/City names. They're great, all proper datetime libs support them, your OS supports them, they're reasonably human readable and completely machine readable. They're better for storage than offsets (or terrible future-incompatible terms like CET) in every way.

Really the entire timezone debacle can IMO be summarized as:

- for datetimes in the past, store UTC. convert from/to local in the UI; just assume the system/browser locale is the one unless you know otherwise.

- for global datetimes in the future, eg comet passings and the likes, same thing.

- for local datetimes in the future, at some "wall clock time in a place", store localtime + an IANA Continent/City combo, and keep your servers' tzdata files reasonably updated.

It never makes sense to store or communicate offsets. It hardly ever makes sense to do geolocation unless you think you think the chance that Berlin moves to a different country than Frankfurt is bigger than the chance that you lose access to up-to-date geolocation information.

Note that the above implies that the option for ISO date strings to include offsets (or words like "CET") is, IMO, nearly always the wrong choice. For past dates (ie 99.9% of dates stored by computer systems) just use UTC, and for future dates, IANA timezone names are strictly better.