Daylight saving time: Computing

Daylight saving time (DST) further complicates the already convoluted timezone handling in applications. This has both good and bad consequences, but as a programmer, I frequently worry that the systems I work with will handle DST incorrectly.

In the last year, I have been working extensively on a system, where we transmit and store dates and times in the local timezone, but never explicitly stating what that timezone is. This means that if there are two events that happened on October 28th, 2018, say at 02:15 and 02:20, it's impossible to tell which event occurred first. All instances between 02:00 and 03:00 occurred twice (in Sweden).

On the other hand, programmers usually don't know very much about timezones and DST, don't think about them at all. If they were interested, dealing with DST constitutes a good local example.

Dealing with timezones - principles

Most programming environments, datetime libraries and frameworks make the following principles hard to follow, but here's what I believe you should do when possible.

• Calendars. In a calendar, you generally want to know which city an event takes place. If we're planning on meeting at 2 pm, we're always talking in local time. If the politicians decide that we won't do DST this year, we'll happily move the appointment one hour without even thinking about it. In a computer system dealing with calendars, we should therefor store the appointment as "2 pm in Europe/Stockholm", whenever the event takes place in Sweden. (Stockholm is a representative city for all of Sweden, always having the same timezone as e.g. Karlstad.)

• Universal events. Events that aren't affected by local timezone rules should be stored as UTC, though generally displayed to the user in their local timezone. Examples might be the time of sunrise or when you wish to be able to sort events by when they occur.