UTC brings its own batch of problems when it comes to local time relative scenarios.

Last time I looked best practice for a real calendar app was to store in local time with time zone, not UTC with offset.

UTC is time in theory. Points in time separated by numbers of seconds. Great until the reality of time being a social construct breaks your assumptions. Still, use UTC until you are actually building a calendar app. Depending on your use case, consider storing timezone instead of offset.

▲ JTbane 9 hours ago | parent | next [-]

That's interesting because I work in industrial data and pretty much everything is stored and logged as UTC to avoid these kinds of mess ups.

  best practice for a real calendar app was to store in local time with time zone, not UTC with offset

	▲	adrian_b 8 hours ago \| parent [-]
		Either UTC or TAI should be used for anything that is truly a "time". The "time" at which future events are scheduled by humans (i.e. not the time when future events are predicted, like astronomical events), is not a "time", but it is a different data type, which must have a different name and which must store different information (i.e. legal date and time at a certain location).

▲ adrian_b 8 hours ago | parent | prev [-]

As another poster already said, UTC is the correct choice for any kind of timestamps and for the storage of any time information about the past. (Actually TAI is an even better choice for these purposes.)

For future events, the "time" when they will occur is not "time", but a different data type, which should be called "legal time", "local time" or the like.

The "local time" for future events must include the geographic location attached to the event, from which the applicable time zone can be derived, at a time close to when the event is due.