Gallery of Stack Traces: Date/Time Fun
As you know, stack traces provide QA with the joie de vivre and esprit de corpse that get us through the day. As part of an ongoing series, I am going to present a series of some of my favorite stack traces that never fail to bring a smile to my face and a Dosso double-snap to my fingertips. From the Gallery today, we have two extra fun .NET stack traces that occur, frequently, when you do naughty things with dates and times.
For example, the following stack trace occurs if the application lets you enter a string that it expects to be a date, but it’s not:
Click for full size
You’ll elicit this stack trace easily when presented with an edit box that allows you to enter a string without constraints that the application expects to be a date. Developers could easily prevent this problem with drop-down lists for month/date/year, separate edit boxes with appropriate validation, or calendar controls. But that would be much more work.
The second stack trace occurs if the application doesn’t check to handle the database’s earliest possible date:
Click for full size
Developers could use different variable types to hold dates or could perform validation to prevent this stack trace, but instead often rely upon the good will and infallibility of keyboardists everywhere to hope this stack trace remains hidden.
And just to be clear, I’d like to be the first to offer the Y10K bug consulting services. Because, as you in the field know, someone’s still going to be using a Microsoft SQL Server and Microsoft IIS platform in 9998 because they paid for the software 7 millennia ago and didn’t feel the need to update it since it worked passibly well since then.
So I guess some thanks are in order; Developers, thank you for leaving off these simple steps so we can log these same issues over and over again for every last application or modification you write.
August 14th, 2007 at 2:59 pm
Here we go again:
>
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.
August 14th, 2007 at 6:24 pm
Jack Straw is correct that it’s a flaw with a datatype that can be rectified with proper use of a better data type, better logic, and such would prevent it.
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.”
August 14th, 2007 at 10:59 pm
No, I was in Minnesota, not Massachusetts.
…and the wedding is another story.
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.” ?
August 15th, 2007 at 8:53 am
You’re the one who’s calling a meeting to discuss platform options when QA says that a stack trace has occurred.
August 15th, 2007 at 10:11 am
Indeed - Your article prompted an interesting discussion over here about a [not so little] “History and Future of the World” database… In the end, it was decided that the platform handling of dates was irrelevant, so long as the platform as a whole could scale acceptably. Dates would have to be “hand rolled” regardless of the platform….
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.