I used
DATEADD(mi, DATEDIFF(mi, GETUTCDATE(), GETDATE()), m.StartDateTime)
to get the local datetime from the original m.StartDateTime column in SQL Server 2017 database, and it works fine for me.
However, when using this in an Azure SQL Managed Instance, the local datetime is still the same as attached screenshot.
StartRunningDateTime_AzureMI_DateTime = StartRunningDateTime_Local_DateTime
I have added the column StartRunningDateTime_Expected_DateTime that 13 hours are added to get correct local datetime. However, my country uses daylight saving, so it will plus 12 hours in others months.
Please help me out how to use DATEADD and GETUTCDATE correctly to achieve the goal.
Thank you in advance.
Related
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.
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
In my SSIS package I read column type datetimeoffset(7) and write to column datetime2(7) (data flow task). Select in Source returns value i.e. '2015-01-01 00:00:00.0000000 +00:00' but in destination I got '2014-12-31 19:00:00.0000000'. This 5 hours difference is related to timezone on server which hosts sql service (both database and ssis package).
Any idea what is cause of this datetime change?
The problem appears to pertain to setting a datetime in the destination that hasn't happened yet on the server in the later timezone.
The following article should address your issue with several options for resolving:
http://www.mssqltips.com/sqlservertip/3173/handle-conversion-between-time-zones-in-sql-server--part-1/
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.
We have a database application that has been running for months, then suddenly it started to give errors.
I noticed a datetime float calculation exception that which was being compared with the value 0,05. I also noticed that dates being written to our xml log file were in the format d.mm.yy.
Clearly, the decimal operator being used is ',' and the date separator is '.'.
The application was initially installed using the UK english regional settings. I checked that the regional settings which were still UK english.
I noticed in the database connection string, the host was given as "servername\instance,portNumber", where as I expected "servername\instance:portNumber" for an normal working installation.
Any ideas where the regional settings are obtained from? Also, could it be the user they are using to run apps against the database or the user that runs the database?
JD.
Control panel.. regional settings.
This sounds like a client app issue too, not SQL Server. If they are installed on the same box, SQL Server does not take settings from the OS locale.
It could be that the user of the app has german locale and some data is being passed as string, when it should be float or datetime already (with client doing locale handling)
SQL Server will also never recognise "0,05" auf Deutsch too.
SET LANGUAGE GERMAN
DECLARE #val float
SET #val = 0,05 --fail
GO
DECLARE #dt datetime
SET #dt = '23 Mrz 2009' --fail
GO
DECLARE #dt datetime
SET #dt = '23.03.2009' --ok
GO
And "servername\instance,portNumber" is correct for SQL Server.