Is there any way to change SQL server datetime? GETDATE() and CURRENT_TIMESTAMP show the wrong dates.
I read that SQL reads the date from the server settings where the SQL instance is installed. But on this server(Windows SERVER 2019) time, date and timezone are correct.
Only in SQL Server are those settings wrong. I've tried to find a solution for this issue over internet but I couldn't find any.
Only SYSUTCDATETIME() shows correct information.
GETDATE() and CURRENT_TIMESTAMP will be working correctly. They return the server's local time. If the time is "wrong" then it's because the time on the server is "wrong"; most likely because it thinks it's in a different timezone to where it physically is or has the wrong DST setting.
Clearly, however, the time is correct on the server for its location (in the sense of that if it's observing CET it would display 11:38 around now) as you state that SYSUTCDATETIME() returns the correct UTC time.
if the server does have the wrong time setting, however, the fix is fix the time on the server. Speak to your server administrator about that. YOu change change the values GETDATE() and CURRENT_TIMESTAMP return as they are based on the host's time. This is why I am confident the time is correct, likely it is either set to the wrong timezone or DST setting as the UTC time is correct.
If, however, the time is correct for where the server is physically located, then the answer is don't use GETDATE() or CURRENT_TIMESTAMP to get the value for your local time, instead (like you have) use SYSUTCDATETIME() or SYSDATETIMEOFFSET() and then convert the time to your timezone in the application layer.
It seems the server timezone was changed since the SQL Server instance was started. Run the query below to verify the timezone SQL Server is currently using:
SELECT CURRENT_TIMEZONE();
If the result is different than the OS configuration, restart the SQL Server instance for the new timezone to become effective.
Related
We're encountering a strange issue with SQL Server 2014, whereby agent jobs that utilize datetime parameters are having their values altered every time someone clicks 'Ok' on the job step configuration.
The month and day are being swapped around with datetime parameters being passed in the following format "dd/MM/yyyy hh:mm:ss" . This alteration happens every single time the configure job step box is confirmed out of - regardless if the value of the parameter has been changed by the user or not.
Initially because we're based in the UK - I thought that this might just be a display formatting issue - however upon confirming both my regional settings and that of the server, that does not appear to be the case.
Additionally these phantom alterations are actually taking affect within the job step command line, as verified by checking:
select command from [msdb].[dbo].[sysjobsteps]
This seemed like a potential bug - brought on by our latest round of patching, but after rolling back those patches - we still have the same issue.
I couldn't find any mention of such a bug anywhere by searching, so perhaps I'm missing something obvious.
Does anyone have any ideas?
I have a simple query:
select df_id
from diasferiados
where df_dia = '17/9/2017 5:20:03 PM'
I run it on PC #1 and works fine.
But when I try to run it on PC #2, I get this message:
ERROR [22007] [Microsoft][SQL Server Native Client 11.0][SQL Server]Conversion failed when converting date and/or time from character string.
If I modify the date as follows (swap day and month):
'9/17/2017 5:20:03 PM'
It works fine on PC #2.
I can't modify my application so it must remain as the first case.
I'm guessing it's something about SQL Server Configuration but just can't find it.
If you need to provide date&time as string literals, you learned yourself that most formats are dependent on regional and language settings.
The 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.
So in your concrete case, I'm pretty sure this query would work just fine on both your PC's:
select df_id
from diasferiados
where df_dia = '2017-09-17T17:20:03'
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
I'm saving a date in a mysql db as datetime using UTC, so if cst time is 2014-07-22 10:34 am in the db it will save as 2014-07-22 15:34. When testing the app locally, osx 10.9, with either local db or connecting to remote db angular formats it correctly as 2014-07-22 10:34 am. When running the app on a server, ubuntu + nginx + sailsjs, the date reads as 2014-07-22 3:34 pm, so it's not taking into account the timezone. On the server I've set the correct timezone using tzconfig, and it shows local as cst and universal as utc. As I mentioned above, I can connect the local sails app to use the remote database and the time gets formatted correctly. So as long as the sails server is running locally the time is formatted correctly, but if I use the sails app on the server the time is incorrect. Any suggestions?
Thanks
I think your question needs a better explanation. It is hard to tell when exactly the date is messing up. Are you saying that when the sails server is moved to a remote server the date is wrong?
I know personally I stopped using date/time formats and make everything a unix timestamp (ie a NUMBER). This is universal and is never translated till I want it to be translated.
I use this in connection with moment.js (on the server and in angular) to translate my times to/from number and in the correct timezone.
This method has helped tremendously because dates can be manipulated by the server, the db or the client or the db adapter. Maybe none, maybe all and it might event be poor design on my part, but after switching to numbers, I never had these problems ever again.
Amazon recently announced support for time zone change in Oracle RDS.
Since this is still not supported for Microsoft SQL Server 2012, are there any workarounds, to obtain functionality similar to changing the whole database time zone?
Since you're asking for workarounds...
We basically totally disregard server time/database time zone and work entirely off of UTC. GetUtcDate() for instance for all 'DateCreated' columns. Since we've committed to that approach we just don't bump up against any issues.
If you need to store the time zone alongside your date data, you can use DateTimeOffset.
The one caveat is that maintenance plans will be run on server time. This has not been an issue because we normalize everything to local time (which is not UTC and not server time) in any of our calendaring programs.
I did this with MySQL on RDS by changing my instance DB Parameter Group to a custom one that I can edit the parameters for.
I then created the following procedure:
DELIMITER |
CREATE PROCEDURE mysql.init_connect_procedure ()
IF NOT(POSITION(‘rdsadmin#’ IN user()) = 1)
THEN SET SESSION time_zone = 'America/New_York';
END IF |
DELIMITER ;
Note: every other instruction on the internet uses the function current_user() instead of user() which did not work for me!
The catch to this configuration is that then you have to give privileges to all your database users to be able to execute this function, or they won't even be able to connect to the database, so for every user and every future user you have to run this command. (and no there is no wildcard access to procedures)
GRANT EXECUTE ON PROCEDURE mysql.init_connect_procedure TO 'user'#'%' ;
I edited the parameter init_connect for to be set as CALL mysql.init_connect_procedure . I am sure SQL SERVER has an equivalent parameter if not the same.
Restart the server and you should be good!
Warning: The user rdsadmin is the root user that only Amazon has the password to and uses to maintain and backup the database. You don't want to change the timezone for this user or you might damage your entire database. Hence the code to make sure it is not this user. I really recommend making sure the user is the same for SQL SERVER, this solution is only for MySQL and is a terrible solution, unfortunatly I had no other choice. If you can avoid doing this handle the timezone on your application end.
I'm trying to get the current time of a remote server running SQL Server 2012 from a client machine. I have this SQL code:
Select SYSDATETIME() as ServerTime
I thought this was exactly what I wanted and since I was using a development machine with my own SQL Server, it worked fine because I never thought the time I got was my own computer time. Then I found out this doesn't work if I wanted the remote machine's date/time. Is there anyway I can get the remote server's date/time when my application starts up? Thank you.
SELECT 'SYSDATETIME' AS FunctionName, SYSDATETIME() AS DateTimeFormat
UNION ALL
SELECT 'SYSDATETIMEOFFSET', SYSDATETIMEOFFSET()
UNION ALL
SELECT 'SYSUTCDATETIME', SYSUTCDATETIME()
UNION ALL
SELECT 'CURRENT_TIMESTAMP', CURRENT_TIMESTAMP
UNION ALL
SELECT 'GETDATE', GETDATE()
UNION ALL
SELECT 'GETUTCDATE', GETUTCDATE()
UNION ALL
SELECT 'SYSUTCDATETIME', SWITCHOFFSET(SYSDATETIMEOFFSET(), '+05:30')
Where +5:30 is IST
Output:
Sql Working Fiddle
Holy cow I got it to work everyone...It turned out I have a default value of the connection string. I also have a .ini file that contains the server's connection string. And I ended up using the default connection string. The rest of my SQL worked because I've reestablished the server's connection string after getting the server's time. I apologize for all the trouble I've caused. I never wanted to ask this but I just couldn't find the fix until now. Thank you for all your help.