Menu
I am developing a VB.Net application that has operations which rely heavily on dates & times. As there could be conflicts on date formats if the application date format doesn't match the server date format what is the best practice to resolve this issue. I know that SQL Server datetime format depend on the server language & VB.Net will use the local machine datetime format. Which means if a user changes the datetime format it will cause problems when inserting.
My idea is to use SELECT GETDATE() on application startup, then identify its datetime format using VB.Net & whenever I try to insert a datetime value I will convert it to the datetime format identified at the application startup.
Is there a better approach to having a consistent datetime formats between the application & SQL Server to avoid comflicts. eg: Mixing a day with a month.
596
The DATETIME type is used when you need values that contain both date and time information. MySQL retrieves and displays DATETIME values in 'YYYY-MM-DD HH:MM:SS' format. The supported range is '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.
Default output format SQL Server outputs date, time and datetime values in the following formats: yyyy-mm-dd, hh:m:ss. nnnnnnn (n is dependent on the column definition) and yyyy-mm-dd hh:mm:ss. nnnnnnn (n is dependent on the column definition).
DATETIME2 has a date range of "0001 / 01 / 01" through "9999 / 12 / 31" while the DATETIME type only supports year 1753-9999. Also, if you need to, DATETIME2 can be more precise in terms of time; DATETIME is limited to 3 1/3 milliseconds, while DATETIME2 can be accurate down to 100ns. Both types map to System.
SQL Server doesn't store a DateTime in any string format - it's stored as an 8 byte numerical value.
The various settings (language, date format) only influence how the DateTime is shown to you in SQL Server Management Studio - or how it is parsed when you attempt to convert a string to a DateTime.
There are many formats supported by SQL Server - see the MSDN Books Online on CAST and CONVERT. Most of those formats are dependent on what settings you have - therefore, these settings might work some times - and sometimes not.
So if ever possible, don't convert dates between DateTime and string all the time! Leave it as DateTime in .NET, use DATE or DATETIME2(n) in SQL Server, and let the dates be in their native format. Use parametrized queries that support the native DateTime datatype so you don't need to convert dates to string and back!
If you must use strings to represent dates for whatever reason, the only reliable way to solve this is to use the (slightly adapted) ISO-8601 date format that is supported by SQL Server - this format works always - regardless of your SQL Server language and dateformat settings.
The ISO-8601 format is supported by SQL Server comes in two flavors:
YYYYMMDD for just dates (no time portion); note here: no dashes!, that's very important! YYYY-MM-DD is NOT independent of the dateformat settings in your SQL Server and will NOT work in all situations!or:
YYYY-MM-DDTHH:MM:SS for dates and times - note here: this format has dashes (but they can be omitted), and a fixed T as delimiter between the date and time portion of your DATETIME.This is valid for SQL Server 2000 and newer.
If you use SQL Server 2008 or newer and the DATE datatype (only DATE - not DATETIME!), then you can indeed also use the YYYY-MM-DD format and that will work, too, with any settings in your SQL Server.
Don't ask me why this whole topic is so tricky and somewhat confusing - that's just the way it is. But with the YYYYMMDD format, you should be fine for any version of SQL Server and for any language and dateformat setting in your SQL Server.
The recommendation for SQL Server 2008 and newer is to use DATE if you only need the date portion, and DATETIME2(n) when you need both date and time. You should try to start phasing out the DATETIME datatype if ever possible
105
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
