I've been working on an integration project recently, using TIBCO BusinessWorks, and encountered an amusing bug. The code was parsing a bunch of date/time strings, and would works correctly except for a very small number of cases where it would fail with some 'Unparseable date' error. It would work for '26/03/2010 03:20' or '26/03/2010 01:20' for example, but fail for '26/03/2010 02:20'.
After some trial and error, head-scratching and Googling the problem was found - the system function used was implemented internally with java.text.SimpleDateFormat, and since the time string didn't specify the timezone the code assumed some timezone (based on locale I guess) that took DST (Daylight Saving Time) into consideration. So in this timezone, when at 26/03/2010 02:00 the clock advanced to 26/03/2010 03:00, the entire hour in between simply didn't exists and this timestamp couldn't be parsed. The solution was to specify a timezone which ignores DST, such as GMT, and in this particular case was done by appending " GMT+02:00" to the string.
So much for the time continuity...
I have to say WOW. It amazes me how much code goes behind the scenes everytime you parse a string into a date. Who would've thought to even test such a case when parsing a date.
ReplyDeleteI do this quite often in C#, and up to now, didn't realize it might hurts performance.
Now I also realize it might cause bugs which can be very hard to solve. Cheers to StackOverflow.
It gets better... Think about the other side of DST, when for example at 26/09/2010 02:00 the clock is moved *back* one hour to 01:00. This means the entire hour between 01:00 and 02:00 happened twice in this timezone, which just perverse. The timestamp 26/09/2010 01:50 isn't well defined because it might refer to any of two points in time, and chronological comparison doesn't work because 26/09/2010 01:50 might have occurred before 26/09/2010 01:20.
ReplyDeleteThat just proves again that DST was created to annoy programmers.. The lesson for me is to always use GMT time in the future.