[karamanolev]

Eh, I don't buy that. Storage in UTC and converting to a local timezone for display / notification purposes has been the standard practice for a looong time.

What I would believe, I don't know if true, is that different applications support subtly different feature sets, integration has varying levels of support and correctness and so on. Additionally, I feel like vendors are incentivized to offer good support within their ecosystem, but integration with the outside world is a second-class citizen.

[happytoexplain]

"Just store it in UTC" will cause bugs for human time, which calendaring is the most complex example of (because it contains basically every other use case). Don't throw away the date and time the user entered. How you store it is the subjective part, as different choices have different risks. But don't just throw it away.

Also, the existence of this thread should be good evidence that it is indeed not that simple.

[ivan_gammel]

Storage in UTC is generally wrong for future events and doesn’t make sense at all for unbounded sequences.

Edit: better approach will be to store event as it was defined and include processing hints, e.g. when next UTC time of occurrence can be reliably established.

[pluies]

> Storage in UTC and converting to a local timezone for display / notification purposes has been the standard practice for a looong time.

All good until summer time kicks in and your recurring 9am meeting now starts at 8am, oops.

[haakonhr]

But summertime is a (at least here) a separate timezone, e.g., CET vs CEST

[happytoexplain]

The point is that humans want a meeting's clock time to change when they travel to a new time zone, but not when their local time changes (either due to DST or a legal change).

Unless of course not everybody invited shares the same DST patterns, in which case it has to change for some of the participants (how do you choose which?).

Also, the relationship between the datetime the user chose and the UTC time you store can be retroactively changed by legislation.

[ivan_gammel]

Timezones change.

[makeitdouble]

UTC storage is standard practice, but not the best practice nor something that solves all the major issues a good application should be dealing with.

I'd qualify it as "good enough to not get fired" grade of decision, for people who don't care that much about calendaring in the first place or have the luxury ignore complex cases (we're back to "why are calendars so hard?")