[mumblerino]

Can’t most of these issues be solved by not using timezones at all on servers?

All data should be UTC; timezones only apply when the data is shown to the user, possibly on the client itself, which likely can automatically display the right time for a UTC date.

[yosamino]

It's a question of knowing your data.

UTC time probably won't always give you the correct result, since timezones and DST aren't fixed.

Say, you want to store the time of your doctor's appointment months in advance.

Here it makes sense to store the time with a timezone - but not the timezone offset. This makes sense because no matter what the government decides about changing DST or moving timezone offsets alltogether - your doctor's appointment is going to be at 0900am at a specific geographic location and since you will physically be there with your watch synchronized to your doctor's.

But say you have an online appointment with your psychotherapist who lives in a completely different timezone (possibly you do not know which one) from you at some specific time in the future.

Here making the appointment via UTC makes sense - to meet up you need a globally synchronized clock.

The hard part: how do you know determine whether you can schedule these two one-hour appointments right after each other and not have a conflict ? I am not sure it's perfectly possible.

[gpvos]

It would be nice if systems monitored time zone definition changes so you could receive a notification like "Due to a time zone or DST definition change, your appointments now conflict". This has probably not been implemented anywhere.

[jonesetc]

You would still store both future times with offset. When calculating an offset for a future time you take the future time and the zone together to determine the exact time with offset. DST is predictable.

[Macha]

> DST is predictable

No it isn't.

* Europe postponed planned DST abolition due to COVID19: https://www.timeanddate.com/time/europe/eu-dst.html

* Argentina had a period of deciding each year what the DST dates would be until one year they just decided not to: https://en.m.wikipedia.org/wiki/Daylight_saving_time_in_Arge...

* Morocco and Yukon, Canada made updates to their DST policies earlier this year: https://mm.icann.org/pipermail/tz-announce/2020-April/000058...

[fanf2]

DST schedules change several times each year, often with little prior notice. They changed in North America in 2007, which caused a lot of pain for software that thinks DST is predictable, such as Microsoft Exchange.

[masklinn]

If you’re actually working with dates (e.g. calendaring), storing dates as UTC is a potentially critical loss of information.

Basically, UTC is mostly fine for recording past events (e.g. event logs though even then pre-1970 events can be problematic), but for any future event it’s very risky, because time zones « move around » sometimes with very little heads up (down to weeks if not days for DST) but a user working in a specific time one expects their stuff to be fixed in their time zones’ frame of reference.

But of course this indices the problem of ambiguity around DST switch & other backwards TZ movements.

[CodesInChaos]

That is usually enough when recording events that happened at a specific point in time. Even then you sometimes want to record the offset in the user's timezone, so you know the relevant local time (e.g. when taking a photo).

But it's not enough for things agreed to happen in a specific time zone (meetings, contracts, subscription billing, etc.) In those cases you have to record the local time and timezone name (plus disambiguation for DST switching) and figure out how to handle changes of the timezone definition (e.g. by updating denormalized UTC representations or offsets).

[SahAssar]

That only works for absolute times. Things like "tomorrow at 9am" are harder since the definition of it depends on the users local time.