False Positives: Doing Time in Code

Coding Time and Date "stuff" is one of the hardest parts of any real world application.

It's messy for reasons beyond the technological ones, but start there, seems like every language does things differently - each languages designer(s) try to get it right "this time" - and frequently has several incompatible approaches - once they realized they missed something in the original design.

If you're very lucky in your assumptions, or very sheltered, you might not get thrown up on the next set of problems: cultural and political.

Joey deVilla (aka Accordion Guy) in Date and Time Calculation lead me to J R Stockton's Date and Time Index and Links page, which includes a - partial?- list of 23 Calculational Pitfalls past, present and future such as : Critical and Significant Dates; Ambiguity; Sorting; Month Stepping; etc.. JR also makes some general suggestions on Algorithms and Coding information relevant for Languages including Javascript, VBscript, Pascal & Delphi.

Also via Joey's post, Anonymous points to Erik Naggum's 1999 paper The Long, Painful History of Time, which was given at the Lisp Users' Group Meeting in Berkeley, CA.

I've blogged on this in Complication in Daylight Saving Time and Global reality: TimeZones+ Daylight Saving Time, is hard, which have links to more resources and cautionary tales, like from Loosely Coupled weblog:

Why is timezone awareness such a big deal? Because it only becomes a problem in a highly distributed, decentralized environment. So long as there's a single, central point of control, then it's easy to wriggle around timezone issues by pretending they don't exist. You can always decide that, since the data center is in Colorado, all transactions will logged using Mountain Time. Or if the company headquarters is in New York, you can decree that everything happens according to Eastern Time.