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

From annawiki
Revision as of 2013-11-11T20:24:58 by Tobiasco (talk | contribs) (Created page with "If an event is scheduled in another time system than UTC, and the offset is not known, one can an only use assumptions about the offset to derived UTC. Still there are websit...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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

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?