Return to Answer

The DateTime2(0) datatype takes up less space on the harddisk (6 bytes per row)

The DateTime2 datatype is searchable.

The DateTime2 datatype is easy to calculate on a date or DateTime2 datatype. Last day of month, etc.

And most important; The DateTime2 datatype travels well; there are many different date-time formats around the world. You never know if your software goes aboard, or your company is taken over by somebody why writes dates as yyyy-mm-dd or mm-dd-YYYY or dd/mm/YYYY or one of the 20 odd other formats that SQL Server support.

Joe Celko has written a lot about this, today I saw this : http://www.sqlservercentral.com/articles/Database+Design/69926/ one quote: "But one of the most common design errors is to use strings for date and time data."

The DateTime2(0) datatype takes up less space on the harddisk (6 bytes per row)

The DateTime2 datatype is searchable, as it is possible to write a query that will span from December 30th 2013 to January 2nd, where the SQL Server will disregard dates before and after. Such a range query is not easy to write with individual columns.

The DateTime2 datatype is easy to calculate on a date or DateTime2 datatype. Last day of month, etc.

And most important; The DateTime2 datatype travels well; there are many different date-time formats around the world. You never know if your software goes aboard, or your company is taken over by somebody why writes dates as yyyy-mm-dd or mm-dd-YYYY or dd/mm/YYYY or one of the 20 odd other formats that SQL Server support.

Joe Celko has written a lot about this, today I saw this : http://www.sqlservercentral.com/articles/Database+Design/69926/ one quote: "But one of the most common design errors is to use strings for date and time data."

The DateTime2(0) datatype takes up less space on the harddisk (6 bytes per row)

The DateTime2 datatype is searchable.

The DateTime2 datatype is easy to calculate on a date or DateTime2 datatype. Last day of month, etc.

And most important; The DateTime2 datatype travels well; there are many different date-time formats around the world. You never know if your software goes aboard, or your company is taken over by somebody why writes dates as yyyy-mm-dd or mm-dd-YYYY or dd/mm/YYYY or one of the 20 odd other formats that SQL Server support.

The DateTime2(0) datatype takes up less space on the harddisk (6 bytes per row)

The DateTime2 datatype is searchable.

The DateTime2 datatype is easy to calculate on a date or DateTime2 datatype. Last day of month, etc.

And most important; The DateTime2 datatype travels well; there are many different date-time formats around the world. You never know if your software goes aboard, or your company is taken over by somebody why writes dates as yyyy-mm-dd or mm-dd-YYYY or dd/mm/YYYY or one of the 20 odd other formats that SQL Server support.

Joe Celko has written a lot about this, today I saw this : http://www.sqlservercentral.com/articles/Database+Design/69926/ one quote: "But one of the most common design errors is to use strings for date and time data."

It takes up less space on the harddisk.

It is searchable.

It is easy to calculate on a date or DateTime2 datatype. Last day of month, etc.

It travels well; there are many different date-time formats around the world.

The DateTime2(0) datatype takes up less space on the harddisk (6 bytes per row)

The DateTime2 datatype is searchable.

The DateTime2 datatype is easy to calculate on a date or DateTime2 datatype. Last day of month, etc.

And most important; The DateTime2 datatype travels well; there are many different date-time formats around the world. You never know if your software goes aboard, or your company is taken over by somebody why writes dates as yyyy-mm-dd or mm-dd-YYYY or dd/mm/YYYY or one of the 20 odd other formats that SQL Server support.