Time is hard

You probably heard about the leap year outage of Azure which is explained here. Essentially it looks like somebody added one to a year (which was probably an integer) rather than using a (proper) date representation. Remember that I do not know, but this is my assumption based on what I've seen over the years. Essentially dealing with time seems to be hard and I think most of the time it is because people don't use a date/time abstraction but take shortcuts based on assumptions that are not correct. Here are some assumptions I've come across in the past:

  • Forgeting leap years.
  • Assuming leap years happen every four years (ex: 1900 was not a leap year).
  • Forgetting daylight savings time.
  • Assuming all countries have daylight savings time on the same date (some countries don't even have daylight savings time).
  • Assuming everybody using your software will be in the same timezone.
  • Assuming all time zones are whole hours from GMT (some countries fraction of hours as offset from GMT)
  • Assuming use of AM/PM rather than 24 hour clock
  • Assuming there are 60 seconds in a minute (ex: leap seconds)

So there are a lot of things to think about when it comes to dealing with time so you should really use an abstraction for it and preferably use an implementation of that abstraction created by somebody who have tested it well such as something being part of whatever framework you use for development.

Comments (1)

  1. gbates says:

    Add : assuming an entire US state uses DST (e.g. Arizona)

Skip to main content