Storing event information in UTC for future events that are not scheduled in UTC

Overview

If an event is scheduled in another time system than UTC, and the offset is not known, one can only use assumptions about the offset to derive UTC.

Still there are websites, even web frameworks that recommend to store event time in UTC in such cases.

If you follow their advises to store data in UTC you may get in trouble.

Assumption changes

For DST countries:

• start or end of DST may differ from predictions

For non-DST countries:

• base offset from UTC may differ from predictions, e.g.
  • in 2007 the UTC offset of the legal time in Venezuela changed

Examples of sites promoting storing in UTC

Django

https://docs.djangoproject.com/en/dev/topics/i18n/timezones/

• "When support for time zones is enabled, Django stores date and time information in UTC in the database" - OK, but does Django also store the real time for which the event has been scheduled?

• "This is handy if your users live in more than one time zone and you want to display date and time information according to each user’s wall clock." - That sounds like nonsense.

• "Even if your Web site is available in only one time zone, it’s still good practice to store data in UTC in your database." - Now they even call it good practice.

• "Many countries have a system of DST" - many more have not.

• "If you’re working in local time, you’re likely to encounter errors twice a year, when the transitions happen." - What kind of errors?

• "I don’t need multiple time zones. Should I enable time zone support?"
  • "Yes. When time zone support is enabled, Django uses a more accurate model of local time. This shields you from subtle and unreproducible bugs around Daylight Saving Time (DST) transitions." - Ouch, not bothered to ask, whether the user will ever use DST? There are countries that never had DST.