Time is not always on your side…
TOPdesk is a product which is used by all kinds of different companies. Some of those companies are small and just have a limited user base, while other companies are multinationals, with end-users all over the globe. Typically this means that you have many users from different time zones, all working together in the same environment.Time zones. A dreaded word in the world of software. Although most people take time zones for granted without even thinking about it, the concept time zones can sometimes pose quite interesting challenges for us software engineers.
One day, we received a call from a customer in Brazil, telling us that the Plan Board would crash when opened in a certain week. The Plan Board contains a planner which allows the user to assign tasks to people in an efficient way. When we got the call, initially we were a bit mystified by the bug. Our first thought was that perhaps the customer’s database got corrupted somehow, causing the crash. When we checked the data however, nothing seemed out of order.
Since corrupt data was ruled out, we started thinking that it could have something to do with time zones. We opened the Plan Board in our own time zone Amsterdam (UTC+1) and nothing happened. We then switched the time zone to São Paulo (UTC-3) and sure enough, the Plan Board crashed. Mind you, this only happened when it was opened in a specific week.
So what was causing the problem? Given that the crash only occurred in UTC-3, we were wondering what’s so special about that time zone? As it turned out, the week where the Plan Board kept crashing, was also the week where Brazil had its DST switch. We finally found the smoking gun, but it raised a new question: why didn’t the Plan Board crash in Amsterdam (UTC+1)? We have DST as well, but the Plan Board was working just fine in the week of our DST switch. Strange…
The Plan Board makes extensive use of Joda Time, an open-source date and time library. Several calculations in the Plan Board were based on the assumption that a day starts at midnight, which by the face of it isn’t an unreasonable assumption to make. Well, we were wrong…
It turns out that Brazil’s DST switch happens exactly at midnight, which means that on that day there is no midnight. In other words, we didn’t have anything to base our calculations on, causing the Plan Board to crash.
Eventually, the reason for the crash were several calls to Joda Time’s LocalDate#toDateTimeAtMidnight() method, which would throw an exception if the date represented by LocalDate did not have a midnight. We fixed the code by using LocalDate#toDateTimeAtStartOfDay instead. The original method was later deprecated and eventually removed from Joda Time’s API.
Another time zone-related bug we encountered, had to do with a difference between the server time zone and the user time zone. In certain cases, the date was stored correctly in the database, but it would show up with a seemingly inexplicable offset in the UI. Apparently, we forgot to do a correct conversion from the server time zone to the user time zone.
All in all, these kind of bugs made us more aware of time zones, when doing any kind of date calculations. We added extensive unit and integration tests to verify that the product will always work, regardless of the time zone it’s viewed in. So instead of only testing in UTC+1, we also test in several different time zones. Since we’ve fixed these bugs, every time we add a new feature which requires date calculations, we make sure that it’s tested thoroughly in various time zones as well.
Unfortunately, it’s not always possible to guarantee that your assumptions are correct. Sometimes the assumptions you make are implicit, like the one we made in the Plan Board. Other assumptions are made explicitly, in which case it’s easier to determine what should be tested. The most important thing is to test whatever needs to be tested. Even if down the road it turns out that an assumption was incorrect, don’t just fix the problem, but also write additional tests verifying the corrected assumption. This way you can be relatively sure the bug won’t happen in the future again.
About Me
-
michael.gr
View my complete profile