Daylight Saving Time begins in the UK overnight tonight. This and the end of DST cause me no end of headaches and worry in my professional life. On the face of it most people do not realise that there is anything difficult about time. To them it seems that 10am on one day is the same as 10am on another day and that they are always 24 hours apart.
One of the rites of passage to becoming a seasoned computer professional is learning first hand how much of a mess can be caused if you don’t take care with your timezones and daylight savings time.
An easy approach that can work well if you control the whole system end to end is just working in localtime throughout. Thus you talk about your appointments being at 10am on a particular day and leave it at that. This can work quite well in the UK where we operate on a single timezone and do not have any direct borders with other countries that use different timezones.
However as soon as you start interfacing with other systems and interchanging data with 3rd parties in other countries then things get very confusing. These days I make sure that whenever I design a system and specify data interchange formats I ensure that times are all passed in a format that includes a timezone. Where possible I use ISO 8601 format to do this.
- Good – 2011-03-27T11:00:00+01:00
- Bad – 2011-03-27T11:00:00
In the second example you cannot tell if the time is 11 am in BST or in GMT. Actually worldwide it could be any number of times if we want to get really confusing.
When displaying a date/time for an end user they rarely care about much more that what the time is in their local timezone. As such in user interfaces a lot of the timezone information can be dropped and where possible that information is picked up from the locale settings on the computer that is displaying the information.
If the information is in a data interchange file then where possible my preference is to store it using the timezone that is most appropriate for the recipient of that data. This should not really be an issue because it will likely be read by computer but it does make it easier for a human to verify the contents and debug the data.
I put quite a lot of effort into adding unit tests into the software that I write to ensure that things work correctly. However when you are working with multiple co-operating systems, especially where some of those are outside of your control, then end-to-end testing is rarely possible in advance. Thus the change to/from daylight saving time is often one of my most fraught times of the year. It is a hard deadline and no matter how much planning/testing you do there are often still a few surprises left in the cupboard.