Which is why you need a company whose business analysts take time to learn your needs to provide you with the best solutions possible at a reasonable rate.

To be an equal-opportunity platform lover, I will mention that while an Oracle Date field can store dates as small as 4712 B.C., it can only handle dates going forward to 4712 A.D. It also supports Gregorian and Julian date functions, but can cost quite a bit more.

IBMs DB2 Date type lasts from 1 A.D. to 9999A.D., does not handle Julian dates like Oracle, but does follow the ANSI/ISO SQL Standard date requirements pretty closely, and is also rather pricey.

SQL Server 2005 DateTime runs from 1753 A.D. to 9999 A.D. and is more reasonably priced. It also supports the .Net 2.0 CLR which means you can define your own date data types in your preferred .Net language.

MySQL can quantum leap you anywhere from 1000 A.D. to 9999 A.D. and some call it “free.”

Given that every other database has a data type supporting dates to 9999 A.D., perhaps the Oracle system is best suited for pre-history data or, “old stuff.” Maybe QA should suggest a migration to Oracle to help alleviate the problem…? It may cost more, and take months to complete, but by golly… writing validation for dates that passed in pre-history would be a little bit easier!

An addition to my previous note – different countries switched from the Julian calendar to the Gregorian calendar at different times. So when you are working with pre-history data, you’ll need to know what country your user is in as well…

Isn’t it easier to just say…
“DataType error – Please enhance validation.” ?

The stack trace is not necessarily the fault of the platform that Jack Straw loves and adores so much (rumor has it he spent a long weekend in Massachussetts actually trying to marry Windows); rather, it’s a flaw of the lazy and/or ignorant developers who work with it.

Also, Jack Straw, you forgot to mention “You need a company whose business analysts take time to learn your needs to provide you with the best solutions possible at a reasonable rate.”

>

QA is great at finding problems.
But when it comes to explaining the reason behind the errors… notsomuch.

There are a number of reasons why the datetime datatype has a limited range in SQL Server, but those reasons are irrelevant. Our QA professional has suggested that you cannot store dates prior to 1753 in SQL Server, which is absurdly false.

True, the datetime datatype may not support it, but if we had built-in features to handle every conceivable data variation, then we wouldn’t need so many developers.

.NET can handle dates from 1.1.0001 forward… and with some reasoned thinking, so can SQL Server.

Consider Format.Native and Format.UserDefined. Format.Native only works with blittable datatypes, and you will have to implement the IBinarySerialize interface along with Format.UserDefined. You can polish off the task by writing a few user-defined functions that work the same as the native SQL Server date functions, but with your custom type instead.

A word of caution: Dates are not simple… if you want to go waaay back in history, you need to accurately account for leap years and also changes to the calendar itself. Before the Gregorian Calendar that we are familiar with today, the Julian Calendar reigned until 1582. Of course, Julian years were longer… The Gregorian calendar also has 3 additional leap-days every 400 years…

Its not that it *can’t* be done… its just not so simple and straightforward as one might like. The real QA issue, is that the developer chose to work within the predefined data types and did not validate input data. Thus… QA could accurately respond with:

Error: DateTime Overflow
Cause: Input Dates not validated

No need to start bashing corporations or products at this point… The chosen database platform hasn’t really impeded your ability to work with dates – instead, it has made it vastly more simple to work with the most common dates. The Duke of Normandy has indeed not been banned from modern computerized history tools.