Comment Re:Design? Lack of foresight? (Score 1) 579
The testers may have thought they thoroughly tested time zone changes, but perhaps there was a piece of bad data laying around that only caused a problem on one side of the world, and only when THAT piece of bad data was in use. Consider the following possibility:
Time zones stored with offsets from international date line. On the Western side of the world, the offsets are negative, and the Eastern side of the world, the offsets are positive. (PST = GMT-8 hours, so offset = -480 minutes). Converting a local date to UTC for storage would involve subtracting the offset from the local time, so local time - -480 -> local time + 480 -> UTC. More importantly, converting a local time from the Eastern side of the world would subtract a positive offset.
A piece of bad data could be some piece of information, such as datetime data that was cooked up before nullable dates were supported, and thus they used DateTime.MinValue to represent a null value. Now suppose they support both null and DateTime.MinValue for backwards compatibility just in case any data or interface was missed.
But maybe the logic that does conversion from local to UTC doesn't know about the old way of representing null, so if it saw that a datetime field had a non-null date in it (such as DateTime.MinValue), it would try to convert it by subtracting the offset. Such a subtraction would not raise any errors if the timezone in question was on the Western side of the world, but subtracting a positive offset from the Eastern side of the world would have caused an invalid datetime value (less than MinValue!), raising an error that was apparently poorly handled.
If they used .NET 1.1, then migrated to .NET 2.0, and had more than one person working on timezone conversion library and/or support for nullable dates, then the above scenario is a real possibility. Happened to my software at work. :)
Time zones stored with offsets from international date line. On the Western side of the world, the offsets are negative, and the Eastern side of the world, the offsets are positive. (PST = GMT-8 hours, so offset = -480 minutes). Converting a local date to UTC for storage would involve subtracting the offset from the local time, so local time - -480 -> local time + 480 -> UTC. More importantly, converting a local time from the Eastern side of the world would subtract a positive offset.
A piece of bad data could be some piece of information, such as datetime data that was cooked up before nullable dates were supported, and thus they used DateTime.MinValue to represent a null value. Now suppose they support both null and DateTime.MinValue for backwards compatibility just in case any data or interface was missed.
But maybe the logic that does conversion from local to UTC doesn't know about the old way of representing null, so if it saw that a datetime field had a non-null date in it (such as DateTime.MinValue), it would try to convert it by subtracting the offset. Such a subtraction would not raise any errors if the timezone in question was on the Western side of the world, but subtracting a positive offset from the Eastern side of the world would have caused an invalid datetime value (less than MinValue!), raising an error that was apparently poorly handled.
If they used
