DateTime and TimeZone explained

I often see code where developers are using DateTime and are not really writing defensive code handle DateTime values. Usually a developer accepts a DateTime, assumes it is in his current time zone and do some calculations. Then days, weeks or months later the developers are notified of a strange issue for example when due to daylight savings time the clock goes back or forward.

Some date time related issue examples:

Then the bug hunting starts and after a long time a eureka moment happens and a developer notices it is because the system is not processing based on a fixed clock. It is nice to notice this as from then on a developers mind regarding date and time is changed forever in favor of mankind. The applied when a long time ago people we only using 2 digits to store years and the millennium was approaching and how leap days affects system behavior and reports.

Thinking about this makes me also want to talk about time zones. This is what happens after a developer learns how to cope with utc and local time values. Usually a system runs in a certain time zone, the company expands internationally and nobody at accounting or sales realizes that when a invoice batch is ran at night that this will be happing mid day for a customer at the other side of the globe. Fun stuff happens here the same for invoice specifications.

Some time zone related issue examples:

This post hopefully makes you aware of common pitfalls. In future posts I will explain on how to address these issues and make a robust design for your system on how to handle such information.

comments powered by Disqus
← Older Newer →