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

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.

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

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?")