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.

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

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.

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.

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...

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.