Pinderkent

One thing I have seen at far too many of the companies I have worked with is the act of reimplementing time and date handling routines. Often times, this is done for relatively simple business software where the time and date functionality offered by Java, .NET, their database server or whatever environment or language they're using would have been more than sufficient. More often than not, this roll-your-own approach to date and time functions or classes turns out to be a huge mistake.

We work with dates and times on a daily basis. For most people, they're relatively natural things to work with. We look at our watch without giving it a second thought. The same for calendars. But implementing correct date and time handling for a software product is just not an easy task. It's a very convoluted and confusing domain to be working in.

In many ways, time and date manipulation just does not lend itself well to being implemented in software. Thoughout history, time- and date-related matters have typically been decided by religious and political authorities. And even when scientists and engineers have been involved, we still end up with inconsistent rules rife with exceptions and absurdities. Developing even remotely correct handling becomes a tedious chore, and mistakes will surely be made.

Today I read an article about the bugs one fellow found in some time and date code he had to work with. I've seen many of these same problems, as well, with code at numerous companies. Home-brewed date and time code is unfortunately one of those common mistakes that is destined to keep happening over and over again. It appears to the developer to be easy data to work with, and often that is the case. But to work with time and dates correctly, that's another matter, posing more challenges than most developers realize.