I have been researching a lot of similar questions on how to convert date format to DD-MM-YYYY but none work for the date format I'm using.
This is the date format I'm working with:
Wednesday, October 14, 2015 5:57 PM
And this IS a "date" field not a text field. I have a feeling that the inclusion of the day of the week is precluding my other attempts from working.
I'm new to SQL so forgive me if I'm overlooking something obvious.
Thank you!
On SQL Server, there are generally four ways to control date formatting.
Control it in your application. Most queries to the database return result sets that are typed. So a datetime column will be of data type datetime or timestamp in your application. You then apply the formatting from your application. The drawback to this is that, well, you wouldn't be asking this question if this were your problem.
Use the CONVERT() function, which allows limited formatting of datetime, datetime2, date, and time fields. SELECT CONVERT(VARCHAR(10),GETDATE(),103) will format the column to dd/mm/yyyy. The drawback to this is that you have to do it for every field you want to format every time you want to format them, and you lose the data typing since you're actually converting them to strings.
Use the SET DATEFORMAT command or the SET LANGUAGE command prior to executing your query. You can execute SET DATEFORMAT dmy; SELECT GETDATE() and your dates will be in dmy format. The drawback here is that you have to run it every time you run a query. Also note that since this returns your columns with data type intact, it's possible that your query analyzer will reformat the dates on you.
If you want to permanently set the date format, then ultimately you need to change the language away from us_english (or whatever the default was that was specified when you installed the server). You can see the list of available language configurations by running exec sp_helplanguage, and you can see the currently configured language for your session by running SELECT ##LANGUAGE. I know it's possible to set up your own languages if you need to, but be aware that's a custom configuration you'd have to deploy if you're running that kind of application.
Language configuration is potentially very complicated, since it's determined by the user, login, database or server, depending on where exactly it's specified. As far as I'm aware, logins inherit the server's default language, and users inherit the database's default language. User language is usually not specifed, but I believe it overrides the login language when present. I've only ever run in configurations where everything was defaulted to us_english, so I've not had much experience with this set up. You can modify it with ALTER LOGIN or ALTER USER, and you can set the default language on the server with sp_configure and on the database with ALTER DATABASE.
Related
None of the previous questions/answers on this topic are working for me; I'm a bit baffled. I've inherited my first SQL Server Reporting Services Report Builder report and was given the seemingly simple task of changing what was a date to a datetime. As you can see below I've successfully modified the underlying query and am getting back datetime types but I cannot FORMAT them as such on the report.
Results of my query:
My first instinct was that simply changing the type of the column (FirstProcessorCompletedDate) from date to datetime would make cue the report tool in on displaying date and time, but no luck. So...
Previous experience with report building tools told me to take the existing reference to the field and replace it with a format statement for that field, kind of like this:
Unfortunately, whatever I add here is getting interpreted as LITERALS by the report builder upon execution. AND YES, I DID TRY AN "=" IN FRONT OF THE FORMAT STATEMENT. This is just one variation of what I've tried.
Clearly this is not the old SSRS-type report building I am used to. I've Googled the heck out of this and searched Stack Overflow but no joy on the answer. I've looked a little at Calculated Fields but this seems like overkill. I don't want to calculate something, just format it.
What am I missing?
Don't modify the underlying query, that was your first mistake. date(time) data types don't have a format, they are binary values and your presentation layer changes that to a readable format. Once you change the "format" of a date(time) data type in SQL Server it is no longer a date(time) datatype, it's a varchar, and Format does not work on a varchar. How would you format the varchar value 'Hello, my name is Jane.' to the style MM/dd/yyyy hh:mm tt? You can't, and the same applies to a string representing a date.
Return the value of your column as a datetime to SSRS (don't convert it), and then change the Format Property of your cell in SSRS (hit F4 when you have the cell selected and you'll open up the cell's property pane) and change the format to MM/dd/yyyy hh:mm tt.
I've recently moved a website from one windows server to a new 2016 box. Everything seems fine apart from one part of the site that is running a sql query but erroring on reading the result of this query into a datareader. If i take the sql being sent by the app to sql server (using profiler) i can run it in SSMS fine, but if i debug the line where the sql is executed in visual studio i see this error:
"The conversion of a varchar data type to a datetime data type
resulted in an out-of-range value."
Now i can see the app passes some dates in this format '1998/08/31', could there be a culture setting in IIS/SQL which might cause a problem?
The best ways to avoid this error are in Sean Lange & Damien_The_Unbeliever's comments.
You should do that.
To answer your question:
could there be a culture setting in IIS/SQL which might cause a problem?
Yes.
Sql Server's dateformat is implicitly set by the language setting. You can see the default settings for each language by querying sys.syslanguages, the default date format for each language is in the dateformat column.
select * from sys.syslanguages;
You can explicitly set a sessions date format with set dateformat ymd; or the sessions language with set language us_english;.
set dateformat {};
set language {};
sys.syslanguages on rextester
We're working on a IOS app using Microsoft's Azure Mobile Services. The web GUI creates date-time as DateTimeOffset fields, which is fine. But when we have the mobile put datetimes into the database, then read them from the database, via Entity Framework, we're seeing them adjusted to UCT. (We see the same thing when we view the records in SSMS.)
I've always been frustrated by the lack of timezone support, in SQL's standard datetime types, and I'd thought that DateTimeOffset would be better. But if I wanted my times in UTC, I'd have stored them in UTC. If a user enters a time as 3:00 AM, CST, I want to know he entered CST. It makes as little sense to me to convert it to UTC, and throw away the offset, as it did to assume that 3:00 AM CST and 3:00 AM PDT were the same.
Is there some kind of database configuration I can do to keep the Azure database from storing the dates in UTC?
The issue is that at some point in Azure Mobile Services, the property is converted to a JavaScript Date object, which cannot not retain the offset.
There are a couple of blog posts describing this issue, and possible workarounds:
https://blogs.msdn.microsoft.com/carlosfigueira/2013/05/13/preserving-date-time-offsets-in-azure-mobile-services/
http://michele-colombo.it/2014/11/azure-mobileservices-how-to-properly-save-datetimeoffset-with-offset/
Essentially, they both take the same approach of splitting out the offset into a separate field. However, looking closely at these, they both make a crucial mistake:
dto.DateTime.ToUniversalTime()
Should actually be:
dto.UtcDateTime
The DateTime of a DateTimeOffset will always have DateTimeKind.Unspecified, and thus ToUniversalTime will assume the source is local, rather than using the offset of the DTO.
There are a few other similar errors I see in the code in these posts, so be careful to test thoroughly. However, the general approach is sound.
We're using a Node.js backend and noticed the same thing with DATETIMEOFFSETs read from our SQL Server database being returned in UTC regardless of the offset. Another alternative is to convert the DATETIMEOFFSET at the query-level so that it is outputted as a string with the timezone information. The following converts a DATETIMEOFFSET(0) field to the ISO8601 format; however, other possible styles can be used as documented here:
SELECT CONVERT(VARCHAR(33), [StartDate], 126) AS [StartDate] FROM [Products];
The new output is now: "2016-05-26T00:00:00-06:00" instead of "2016-05-26T06:00:00+00:00"
Of course, this means that the client must serialize the string into their respective format. In iOS, the ISO8601 library can be used to read the output as either a NSDateComponents or NSDate.
One benefit of this approach is that any database-level checks or triggers can do date comparisons using the DATETIMEOFFSET instead of trying to take into account a separate offset column with a basic DATETIME.
I have a vb6 application and it linked to an MS SQL Database via Windows DSN. The application is using rdo connection to connect to the database and tables. Recently my users upgraded their OS to Windows 7. Now they have an issue with the dates whenever they do a posting or updates. Although the system default short date format is set as dd/MM/yy, the application keeps posting the dates to the database as mm/dd/yyyy.
The strange thing is that within the codes the date has already been formated per below
rsPO("LAST_UPDATED_DATE") = Format(Now, "DD/MM/YYYY hh:mm:ss")
so why is it still saving the date as mm/dd/yyyy?
Try with ISO format date. It is a universal date format and works in all DBs
rsPO("LAST_UPDATED_DATE") = Format(Now, "YYYY-MM-DD hh:mm:ss")
Dates are not saved in "dd/mm/yyyy" or any other particular format into the Database.
You just should make sure to use a format to save it in the same manner understood by the application, the OS and the DataBase
Then you can show it the format that you like.
ISO format works ok in most cases.
Date interpretation is a language thing. It's not set by the language on the client computer. It's set by the language of the login making the connection to the SQL database. There are a couple ways you can change things so that it is language independent.
Since LAST_UPDATED_DATE is a DateTime, you should be able to do this:
rsPO("LAST_UPDATED_DATE").Value = Now
If not, then you should format your dates like this: YYYYMMDD.
rsPO("LAST_UPDATED_DATE") = Format(Now, "YYYYMMDD hh:mm:ss")
Read more about it here: Setting a standard DateFormat for SQL Server
To make our developers into the context. The problem is not with stored Date in the database, but the problem happens when we call select for example select * from ... where Date_import ..... This date_import is getting into the database with the format mm-dd-yyyy by default. So the problem is with the String request SQL and not at all with your code or with how data is stored. The solution is to set all your code with YYYY-MM-DD instead of DD-MM-YYYY.
We have a problem affecting the production environment only.
We have a VB6/ASP website that allows for data in a database table to be hand edited.
It looks alot like an editable datagrid.
One of the editable columns is a date and when the record is saved dates day/month are being reversed.
03/11/2008 becomes 11/03/2008, if you were to resave the record the date is again 03/11/2008.
I have checked the DB value and it is indeed being reversed however the same identical code on the test systems does not do this.
So i'm very confident i'm looking for an environment change. The test system has the DB and Site hosted locally and in the live setup we have a separate web site server and database server. Where do you suggest I start looking for this problem. I've checked the regional settings on the servers and they are set to United Kingdom and the OS date format is correct.
This is SQL Server 2000. hit me with some ideas!.
Thanks :)
If you convert the user supplied string to a date before you feed it to the DB, then the Session.LCID of the thread executing your ASP page is responsible for how dates are interpreted.
If you feed the date as a string to SQL Server and let the conversion happen there, it will be useful to look into the SET DATEFORMAT and the SET LANGUAGE statements.
So here is my idea: Either stop using (encouraging your users to use) ambiguous date formats, and this problem will disappear, or make sure all links of the processing chain have a clear understanding on what format to expect.
This is almost certainly to do with either your machine or the db server being set to US date format. Double check both the system settings.
Alternatively, a quick Google search will bring up a few options for manipulating the data so it will do what you need.
How about the regional settings of the OS?
The following
select name ,alias, dateformat
from syslanguages
where langid =
(select value from master..sysconfigures
where comment = 'default language')
Returns the same result on test and live
us_english English mdy
The problem is the system cannot be redeployed to changed. I need to identify the cause and fix it.
Go into regedit and go to the following location in the Windows Registry:
HKEY_USERS.DEFAULT\Control Panel\International\
Check to make sure that the "sShortDate" field is correct.
The short date format stored in this location many times is different then the short date format stored in the Windows Control Panel/Regional Options. The short date in the regional options is for the user that you are logged into Windows as. The "sShortDate" field in HKEY_USERS in the short date format used by the Windows Services.