4 ms·
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
by soco 6y ago
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_ 6y agoDing 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.
- soco 6y agoThere'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.
- user-the-name 6y agoAnd if the timezone changes, should the meeting you booked at 9 AM now happen at 8 AM?
- seszett 6y agoYou 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 6y agoIMO 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 6y agoYou 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.