[soco]

The GUI elements should have nothing to do with storing and interchanging timestamps. What you display can query the browser timezone to make it look nice, then send it down converted, over.

[stefan_]

Ding ding ding, we got a winner. No, absolutely do not query the timezone once then "convert" (aka remove) the information. Timezones change all the time.

[user-the-name]

And if the timezone changes, should the meeting you booked at 9 AM now happen at 8 AM?

[soco]

There's a (fresh) extensive comment right above mine which explains the 4 different use cases for dates and the very minimal real need of TZ, let's all read it. Sorry I cannot comment otherwise your arguments because you didn't offer any.

[seszett]

You cannot convert a time string in the future to a timestamp. You must keep it as a string with timezone information until the time actually comes.

[netsharc]

IMO depending on the use case, just the TZ info won't save you. Say I arrange a meeting for 4pm local time (where summer daylight savings time will be active) for July 2022.. and then the city I want to meet in gets invaded by a foreign army and changes its timezone. And cancels summer time. What time is my meeting now?

I guess it needs to be a 4-dimensional coordinate, where 1 axis can slide around...

[seszett]

You should store TZ info in the "Europe/Brussels" form, rather than "CET" or "UTC-1" which aren't easy to use anyway.

If a foreign army invades Belgium and changes its timezone, Europe/Brussels will get updated.