In SQL Server 2008 R2 if I do:
select SYSDATETIMEOFFSET()
I get back GMT -6.
The TimeZone in Windows that SQL Server is running on is set GMT -7.
Any ideas why there is a difference? Is there somewhere in SQL Server I need to set the TimeZone?
I would guess this is due to Daylight Saving Time being active. Your timezone is officially titled "GMT-7" meaning that normally (not in the Daylight Saving Time part of the year) your time is 7 hours earlier than GMT. But during Daylight Saving Time, that time is adjusted (usually by an hour, but can differ by timezone). So if you were currently in Daylight Saving Time, even though you are in the "GMT-7" timezone, your clock is currently only GMT-6 (6 hours earlier than GMT). I suspect SYSDATETIMEOFFSET() is telling you your actual offset from GMT at the moment as opposed to your timezone's "normal" offset from GMT.
MSDN says SQL Server uses the Windows settings:
SQL Server 2012 obtains the date and time values by using the
GetSystemTimeAsFileTime() Windows API.
Perhaps you have to restart the SQL Server service after you change the time zone?
Related
I am trying to find a way to change SQL server from using UTC time to Local time. This is because I need to be getting Local time when I pull data using ODATA via excel.
Is there a way to configure the SQL server from UTC to local time?
If you have UTC date/time values stored in a datetime, datetime2, or smalldatetime column, you can use AT TIME ZONE to indicate the current value is UTC and to convert the value to the time zone of your choice:
SELECT YourUTCDateTimeColumn AT TIME ZONE 'UTC' AT TIME ZONE 'Pacific Standard Time' AS YourLocalDateTimeColumn
AT TIME ZONE returns a datetimeoffset data type. This can be cast back to the source type if datetimeoffset is problematic for your use case:
SELECT CAST(YourUTCDateTimeColumn AT TIME ZONE 'UTC' AT TIME ZONE 'Pacific Standard Time' AS datetime2(3)) AS YourLocalDateTimeColumn
SQL Server's local timezone is derived from the local operating system. If you wanted to globally affect the timezone that SELECT GetDate() uses, then you can change the time zone of the server.
This is a workaround that is not often recommended to a much larger issue.
Since 2005, the best practice for handling date and time in .Net is to use DateTimeOffset, and this advice became standard in SQL Server 2008. Storing times in DateTime is an anti-pattern that forces a lot of manipulations but worse, it forces a lot of asumptions, for instance how do you know that the value is a local time or UTC, and then which local time zone was used and was it daylight savings or not?
DateTimeOffset provides us with correct sorting and time difference calculations for values that might be entered in different time zones, read more in my blog: Why was DateTime removed from OData v4
If you are querying through an OData API, then you can implement the conversion of timezones in the API logic, or you can manipulate the SQL queries direct, either via middleware, custom serialization or other injection techniques. To go into specifics would however require you to post your associated code.
This answer from #Dan Guzman shows some examples of using AT TIME ZONE in your SQL queries directly, which was introduced in SQL Server 2016. You might also be interested in TODATETIMEOFFSET() or SWITCHOFFSET() but implementing these functions still requires assumptions about the specific time zone to either be hardcoded into the API logic or to be passed through from the client.
It can be done, but when consuming the data in Excel, via an OData API from an SQL database there are multiple points where the conversion logic can be implemented, therefor multiple plausible solutions.
Don't forget, you could apply this time zone logic as a transformation step inside Excel after the data has been retrieved. I hope this post inspires you to research a bit further and to choose a specific pathway. Then if you get stuck, please post a more focused question that details your specific attempt. We are here to help ;)
I was investigating a SQL Server Agent job which I have firing every 15 mins.
It is currently about 3:15 PM on Friday 17 June 2022. (Doing this long hand coz some people might get confused if I say 17/6/2022)
I can see the job history says it ran every 15 mins but stopped at 12 noon. Then it ran at 8:03 pm, 8:15pm, 8:30 pm.
Thing is, it's not that time yet! Like I said it's now around 3:15 pm.
What the heck is going on?
SQL Server version 2017 standard edition.
If it helps, like maybe there is some weird time zone thing going on I am in Sydney Australia. So GMT +10.
The time is correct on the server.
When I do SELECT GETDATE() it also returns the correct time.
My SQL Server Agent job runs everyday 7 PM. How can I disable it to not run every 10th, 11th and 12th date of the month?
Now every month, On 9th, after completion of the job, I do manually by changing start date of the schedule to 13th. Is there any better approach get rid of this manual activity?
My job scheduler has a behavior I can't understand.
It is schedule to fire in the following conditions:
Occurs every 3 month(s) on day 1 of that month at 00:00:00. Schedule will be used starting on 30/09/2015.
So I expected to see it launched next july at midnight and this OK for years.
But it started this night (1st of june).
The script and database have been completely reinstalled on next 5th of may for a migration.
I am using SQL Server 2012 on an on premises server.
Does anybody has an explanation?
Thank you
I'm using an sql server 2005 hosted in the states. Soon we will move the db to Europe.
I'd like to update the dates in the db to take into account the timezone difference.
Is there a good way to do this?
Or is it just a case of looping through the dates and adding the timezone offset?
Does it really need to change because it was physically moved? If you're supporting global applications I would store all my date/time information in GMT and translate to local on the client side.
I think you should be saving the date/times in database in a constant timezone it can be either GMT (because it is pretty simple to transform it into other timezones) or the current timezone of the server if it is not GMT.
Th eonly reason the later option makes sense is that you use the CURDATE function to insert/filter records from the database otherwise GMT is the best option.
You can try using DATEDIFF with DATEADD but due to DST this will not always give the accurate time (off by 1 hour in some cases).
There is a known limitation in SQL Server 2005 about timezone conversions, please refere to the following link for more information:
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=308563