Skip to content
Code To Live By » Uncategorized » Storytime: “Fun” With Timezones

Storytime: “Fun” With Timezones

  • by

A question that I frequently get asked on job interviews and other such things is some variant of “What is the most interesting problem you’ve worked on?”

One comes to mind very quickly.

I was part of a team tasked with maintaining financial regulatory software. A big part of this was tracking things such as birthdays, dates of incorporation, etc. Most of our development team was predominantly based in the United States, but we had a QA team predominantly based in Ukraine.

One day, a bug report comes in. One of our testers had entered a person’s information and submitted, but upon viewing the form after submission realized that the birthday was incorrect. The birthday was shown as being the previous day.

In order to paint some of the underlying technical picture: our database was storing dates as Unix timestamps. When these dates were retrieved we would simply set the “time” component of the date time to midnight for “dates” such as birthdays and display only the date component. There was also a client side conversion done in order to account for the offset in the user’s timezone.

We try submitting the exact same information on developer machines but we are unable to reproduce the problem. Testers send over screenshots to confirm that, yes, this is in fact a consistently reproducible issue.

We begin to go through what might be different between our QA testers and our developer machines. Our developer machines were set to US Eastern time. On a hunch I try changing the timezone on my laptop to the Kiev, Ukraine timezone which has a UTC+2 offset. In Windows 7 this was also combined with Helsinki Finland, Riga Latvia, Sofia Bulgaria, Tallinn Estonia, and Vilnius Lithuania into what Microsoft calls FLE (Finland, Lithuania, Estonia) Standard Time. I am able to reproduce this issue.

I try in other timezones. We had several colleagues in the United Kingdom. I set my laptop to GMT Standard Time. I cannot reproduce the issue. I try other timezones in the UTC+2 offset. Cairo, Egypt does not reproduce. Damascus, Syria does not reproduce. Kaliningrad, Russia does. That sure is strange! I wonder what commonalities there could be?

We soon realize that there is a commonality that covers most of the affected areas, they were former Soviet Union. After some googling we notice something very interesting. Ukraine, before 1990 and while the Soviet Union still stood, used Moscow Standard Time which has a UTC+3 offset. Several of the other countries included in Microsoft’s “FLE Standard Time” could say the same; Estonia, Latvia, Lithuania all used Moscow Standard Time until 1989.

The person who we had been using in our test case had been born in the early 1980’s. The offset that was being used for our client side conversion was being calculated as of present day. However, considering timezones such as the Ukraine timezone that have different offsets based on what year it is, we should have been getting the offset as of the date that we were converting.

The actual offset was one hour past what we were correcting for in our conversion, so the date would end as up 11 PM the previous day, and since we were only displaying the date to the user it would show their birthday as being the previous day.

And if you’re wondering why countries such as Bulgaria and Finland are being included into a timezone that uses Moscow Standard Time prior to the fall of the Soviet Union, so were we. Ask Microsoft.

Leave a Reply

Your email address will not be published. Required fields are marked *