In SQL server, I have a date string that looks something like 09/08/2021. Representing dd/MM/YYYY. So in this case its 09 August 2021. Every method I attempt converting this explicitly into a date format automatically converts this to 2021-09-08. So SQL incorrectly converts to 08 September 2021.
SELECT TRY_CAST(Convert(VARCHAR(15),'09/08/2021',103) as date);
SELECT TRY_CAST(Convert(VARCHAR(15),'09/08/2021',111) as date);
Both incorrectly give:
2021-09-08
Desired result is:
2021-08-09
I've tried the various different versions of the above but keep getting the incorrect conversion. I don't really want to go down the road of changing the source data either.
I am amazed no similar question has been previously asked regarding this.
How can this be converted explicitly using functions in SQL Server?
As per the comments, it was the conversion that was the mistake. Adjusted to
TRY_CONVERT(DATE, '09/08/2021', 103)
This fixes the issue.
Related
I have an issue with SSRS where when posting in a DD/MM/YY value via URL string into a Parameter it decides to read the Day value as the Year, the Month as month, but the Year goes into Day value, for example:
I am inputting the date of 30/08/17 via an ERP System which then generates a string to be used as an URL to generate the report, this date value should then go into a parameter called fiAsOfDate which is Date/Time data type, but at this point it is reading the value as 08/17/1930 inside the Parameter list, even though the URL remains at 30/08/17.
This happens prior to the Query being processed, and the fiAsOfDate parameter then gets formatted through to to MMDDYYYY to be processed within the Query, but the issue is specifically when the parameter is having the value loaded from the URL into the parameter value, and I was hoping if anyone could assist me on this please?
I should also add, this original date is coming from an ERP system which will have regional based date formatting, as it is used internationally, so I cannot restrict myself to one input format, and it should be using regional settings, matching that of the Reporting server that it is based on.
Kind Regards,
James W. Acklam.
To avoid regional setting issues you can change the date into a known integer or string format: I use CONVERT(NVARCHAR, YourDate, 112) to get a string '20170830'. The regional settings won't recognize that as a date and so won't auto-parse it into MM/DD/YYYY or DD/MM/YYYY. Of course, you'll need to parse that yourself so you can use it in the report, but at least you know the format.
This issue was down to my own misunderstanding that the DataSource I was pulling data from worked only in DMY format. Converting dates from parameters format to DMY format and processing that through the DataSet's query resolved the issue.
I have a VB6 application where I insert a set of dates into a SQL-SERVER. Each time I insert a value, it gets inserted as 1978-12-12 00:00:00.000. Is it possible to specify in the INSERT statement, how you want the date to be formatted? VB6 does not seem to recognize CONVERT. I did previously CONVERT date when I loaded it into a MSHFlexGrid like this:
Convert(varchar,tblClient.DOB, 101)
But I did this in a select statement. Will SQL let me insert a value in a format MM/DD/YYYY as I need it later in that format.
The reason why I need the formatting is because I connected all my tables in SQL-SERVER2008 to Access for report generating purposes. So I need it formatted correctly in SQL-SERVER2008 as it dynamically connects to Access.
Ideally, the data type of the column in the database is set to Date or DateTime. Basically, if you want to store a date, then use a date date type.
That being said, in VB6 you usually have to (at least temporarily) store the date as a string so there is almost always a string to date conversion that happens somewhere.
Will SQL let me insert a value in a format MM/DD/YYYY
Yes. But you should not do this. Instead, you should insert the date with the format "YYYYMMDD". Notice that there are no delimiters. The problem with mm/dd/yyyy is that it could accidentally be interpreted as the wrong date. For example, 1/2/2015 would be interpreted as Feb 1, 2015 if you lived in England, or Jan 2, 2015 if you live in the US. However, SQL Server will always interpret 20150102 and Jan 2, 2015.
Once you have the data stored the way you want in the database (as an actual date data type), you should actually return it as a date to your front end (either Access or VB6). In the front end, you should use the format command to display the date. The format command will use the regional settings of the computer to display dates the way the user wants to see it.
Ex:
txtDateOfBirth.Text = Format(rs.Fields.Item("DOB").value, "Short Date")
Doing things this way... you should never have problems with dates.
The best way is not to store formatted dates in your database server.
One way you can get what you want is by using a view where you format your data and use that as input for your report:
CREATE VIEW myreport
SELECT replace(convert(NVARCHAR, mydate, 106), ' ', '/') from mytable
But I would recommend formatting dates on the application level.
You can use VB6s format function prep the date before inserting it into SQL. Here's an example (tested in VBA).
Format(Now(), "YYYY-MM-DD")
I would like to keep my dates as datetime datatype by also be in MM/DD/YYYY format. I know how to do this by converting them to a varchar, but want to keep the datetime format. Can anyone help with this?
Currently I have tried
SELECT CONVERT(datetime, GETDATE(), 101)
which is not working...
There is a basic misunderstanding in your question. Repeat after me: Datetimes don't have a format.
It helps if you think of them as just an array of seven integers (year, month, day, hours, minutes, seconds, milliseconds) with certain constraints. That's not in any way accurate, but it helps to get the notion out of your head that something akin to 12/31/2015 is stored in your database.
Datetimes only get a format when (implicitly or explicitly) being converted to strings. You already know how to set the format when explicitly converting to string, now all that is left to do is to find the implicit conversion that is obviously bothering you and replace it with an explicit one.
Date and datetime Values stored in the database are NOT in any recognizable format. They are stored in binary (1s and 0s) in a proprietary format where one part represents the number of days since a defined reference date (1 jan 1900) in SQL server). and the other part represents the time portion of the value. (in sql server, its the number of 1/300ths of a second since midnight.)
ALL formatting of dates and date times, no matter what format you wish for, is done only after the values have been extracted from the database, before you see them on screen, in whatever application you are using.
You can find all the formats that the SQL Server convert function can use on this MSDN Convert Link
I have a numeric field in my Oracle database that represents the number of days since Dec 28, 1800. However I am trying to select it (for another application) as the current date it represents. I'm not too familiar with Oracle commands (I'm used to SQL), so I was wondering if anyone could provide some assistance. Thanks.
ex: 77650 = Saturday, August 3, 2013
Firstly, get this out of the way, your life would be easier if you stored dates in a date data-type.
However, to answer your question to add days to a date in Oracle you can use the + operator.
Firstly though you have to have a date so I'll convert the 28th December 1800 into a date using to inbuilt to_date function then add the number. In your case you would want:
select to_date('1800/12/28','yyyy/mm/dd') + 77650 from dual
I've set up a little SQL Fiddle to demonstrate for you.
I have a legacy application where the input is a date string, i.e.:
06/12/2009
The format of the input is always a string, and is consistent, it's always dd/mm/yyyy
At the moment the legacy app just INSERTS this in a DateTime fields. Obviously if the Localization Culture settings of the Server change, we have a bug.
Two questions:
One:
Whats the safest way to store Dates in SQLServer in this situation?
Is there a format that will always be correctly interpreted regardless of the order of day and month?
Two:
What settings exactly determines the culture of a SQLServer DB, is it an OS setting, or a setting of that DB, or what?
cheers
Format YYYY-MM-DD is unambiguous, meaning that SQL Server won't confuse the month
and day when converting a string value to DATETIME. (I've never experienced a problem with an implicit conversion using that format using the four digit year.)
The "safest" (and most convenient) way to store date values in SQL Server is to use DATETIME datatype.
Use the CONVERT function to explicitly specify the input and output formats when converting between DATETIME and strings.
SQL Server 2005 Documentation on CONVERT style argument values:
http://msdn.microsoft.com/en-us/library/ms187928(SQL.90).aspx
To convert a string representation to DATETIME datatype:
select CONVERT(datetime, '2009-06-03', 20)
The first argument is datatype to convert to, the second argument is the expression to be converted, the third argument is the style.
(style 20 is ODBC Canonical format = 'YYYY-MM-DD HH:MI:SS' (24 hour clock)
[FOLLOWUP]
To convert a DATETIME expression (e.g. getdate() to VARCHAR in 'YYYY-MM-DD' format:
select CONVERT(varchar(10), getdate(), 20)
Note that specifying varchar(10) gets you just the first 10 characters of the etnire 'YYYY-MM-DD HH:MM:SS' format.
[/FOLLOWUP]
As to what determines the default formats, that's going to be research. We avoid the issues caused by default formats by specifying the formats.
I would recommend storing all dates in UTC time when they are placed into the database. It will be consistent that way.
Storing dates like this seems to work well...
YYYY-MM-DD
See SET DATEFORMAT. The SQL 'culture' is set by SET LANGUAGE at a session level. SQL Server has its own date format settings, independent of the hosting OS. This is for several reasons: ANSI compliance, to prevent OS changes from affecting applications using the database hosted on that host and not least is compatibility, the SQL long predates the OS is currently running on.
Keep in mind that DATA is not its PRESENTATION. In this case that DATA is a DATE or DATETIME, regardless of how you show them.
As for inserting/updating/comparing datetime values, I quote the BOL:
When specifying dates in comparisons
or for input to INSERT or UPDATE
statements, use constants that are
interpreted the same for all language
settings: ADO, OLE DB, and ODBC
applications should use the ODBC
timestamp, date, and time escape
clauses of:
{ ts 'yyyy-mm-dd
hh:mm:ss[.fff] '} such as: { ts
'1998-09-24 10:02:20' }
{ d 'yyyy-mm-dd'} such as: { d '1998-09-24' }
{ t 'hh:mm:ss'} such as: { t '10:02:20'}
I can assure you that, if you use this formats they will always work, regardless of the locale of you server
I'm a bit conservative in these matters, but I prefer to use separate Year / Month / Day fields in the table, rather than a Date field that uses a DBMS-specific data type. It certainly takes more space, but the lack of ambiguity and increased portability is worth it to me.
The price you pay is that you don't get free date/time arithmetic and sorting, but it's easy enough to do yourself or by a slightly more complex "ORDER BY" clause.
I agree with the advice from spencer7593, but please be aware that using cast or convert without a format can give unexpected results. This T-SQL query returns 12, not 1.
set language British
select month(CAST('2016-01-12' AS datetime))
Normally I prefer to insert as
insert into tbl values('yyyyMMdd')
Then, itll be inserted in proper format based on db.