The only problem I could see is that date format is affected by location/regional settings. Today is DEZember in Germany, for instance. If the servers language setting is US English then you are okay with someone using 10-DEC-2009 but then you run into the question of how folks input/how the apps work/etc.

Specifying the month name, as you suggest, eliminates much of the problem with the DD-MM-YYYY|MM-DD-YYYY differences that divide the world. The ISO format (or the ODBC Canonical format) are both internationally liked and accepted regardless of code page on the server, regional or localization settings. But then there may need to be some converting/etc.

So while I use it as a best practice, I look at the bigger picture… Is this app international? Will It be? If it is how will local settings/regional settings and multiple data sources affect it? I try to play to the widest audience with the dates and play it safe. That being said, I have also been involved in projects where we used the format you specify or something similar.

The good news is that either approach is still stored as a datetime in the database so either format should have no impact on the use (or not) of an index.

My preference when dealing with dates has been to fire them into a database in the format dd-mmm-yyyy (eg 08-Dec-2009, 12-Aug-2008) and leave the database engine decide how it wants them to be stored. Whenever I am working with developers I get them to code the applications to always display in this format and only accept user input in that format. Noone does the conversion to a ‘digital date’.

Does this conflict with your advice and the use of the ISO standard? I have never experienced any problems with my solution but would happily revise my ideas if it is a risk..?

Thanks for the post and the reminder about the Primary Keys, they so often are clustered its easy to fall in to the routine by default.

Cheers

Jonathan