Well, not really. :) Timezones are the whole area that has the same time. So "Europe/Berlin" and "Europe/Rome" right now can be used in user-facing help texts to make the timezone understandable, but those cities might not be in the help text in the future. That's because:

"Each time zone is defined by a standard offset from Coordinated Universal Time (UTC)." (https://en.m.wikipedia.org/wiki/Time_zone)

So the offset is the timezone.

That's why I stand with my original point: if you want to support "clock on the wall" future dates, a geolocation is needed. And given that Germany was two countries in the recent past and Frankfurt and Berlin were in different countries, I wouldn't solve this by picking a city from the help text that's currently closest to the timezone, but instead use the actual geolocation of the event.

P.s. All this is, of course, for 99.99% of the cases a complete overkill, and as said, I haven't had issues in using unix epoch for all dates. But just wanted to say that timestamps aren't as simple as I felt was suggested in the first comment.

The offset changes twice a year in many countries due to the misbegotten Daylight Saving Time. What's worse, governments can and do change the dates of the transition so you need something like the Olson (RIP) database to do retroactive time calculations. The US changed its DST dates in 2007, for instance.

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.

Or in 2027 the Sith Empire could conquer Earth and install imperial time system. Good luck with your timestamps. Just make your scheduler as a walled garden SaaS - no need to exchange timestamps.