Using AT TIME ZONE to get current time in specified time zone - sql-server

Question

I am trying to use the new AT TIME ZONE syntax in SQL Server 2016 and Azure SQL. I'm just trying to get the current time in London as a datetime, adjusted for daylight saving. At the time of running all of the commands below, the time in London was 3.27am.
The first step is to get a datetimeoffset, which I can successfully do as follows:
DECLARE #dto datetimeoffset
SET #dto = (SELECT GETUTCDATE() AT TIME ZONE 'GMT Standard Time')
SELECT #dto
This returns a value as I would expect:
2016-04-04 02:27:54.0200000 +01:00
Next, I want to convert that to a datetime, which is what my applications expect. I've tried three different approaches, none of which give me the result I'm looking for:
SELECT SWITCHOFFSET(#dto,'+00:00')
-- Returns 2016-04-04 01:27:54.0200000 +00:00
SELECT CONVERT(datetime, #dto)
-- Returns 2016-04-04 02:27:54.020
SELECT CONVERT(datetime2, #dto)
-- Returns 2016-04-04 02:27:54.0200000
I feel like I'm missing something obvious - is there an easy way to take a datetimeoffset and return just the date/time part at that offset?

Answer 1

The first line of your code contains the fault:
SELECT GETUTCDATE() AT TIME ZONE 'GMT Standard Time'
GETUTCDATE() returns a datetime, which has no time zone offset information. Thus as described in the MSDN documentation:
If inputdate is provided without offset information, the function applies the offset of the time zone assuming that inputdate value is provided in the target time zone.
So, even though you retrieved the UTC time, you erroneously asserted that the value was in London time (which is UTC+1 for daylight saving time at this date).
The easiest way to handle this is to just fetch the UTC time as a datetimeoffset to begin with.
SELECT SYSDATETIMEOFFSET() AT TIME ZONE 'GMT Standard Time'
This invokes the conversion functionality of AT TIME ZONE, which in the docs states:
If inputdate is provided as a datetimeoffset value, then AT TIME ZONE clause converts it into the target time zone using time zone conversion rules.
Consider that if your data actually comes from a datetime field somewhere, you might need to use both parts of the functionality, like this:
SELECT mydatetimefield AT TIME ZONE 'UTC' AT TIME ZONE 'GMT Standard Time'
The first call to AT TIME ZONE asserts the value is in UTC, giving a datetimeoffset to the second call, which converts it to London time.
The output of any of these is a datetimeoffset, which you can cast or convert to a datetime or datetime2 exactly as you showed in your original question. (Don't use switchoffset for this.)
Also, the Windows time zone identifier for London is always "GMT Standard Time". It is inclusive of both Greenwich Mean Time and British Summer Time, with the appropriate transitions between them. Do not try change it to "GMT Daylight Time" - that identifier doesn't exist. This is also covered in the timezone tag wiki, in the section on Windows time zones.

Answer 2

Since I was unable to find this anywhere else I thought I'd share. You can get the offset in minutes by using datepart (tz) with AT TIME ZONE.
datepart(tz,UTC_Date AT TIME ZONE 'Central Standard Time')
select dateadd(MINUTE,datepart(tz,cast('2018-07-02 17:54:41.537' as datetime) AT Time Zone 'Central Standard Time'),'2018-07-02 17:54:41.537') as CentralTime
returns
CentralTime
2018-07-02 12:54:41.537

Answer 3

I suggest you only store this as a string and qualify that it is a local time representation, otherwise the time SQL Server stores internally would be the wrong actual/physical time, if the server time is correct, but just not in the same time zone. It is why you cannot use convert to represent the same because you are actually changing the datetime value from the real time of occurrence and not just re-representing it i.e. Datetime is always stored as UTC, but entered and displayed in the timezone of the server, so if you enter a local time in a datetime field, the server interprets that time as the time in the server time zone and not the actual time of the event, which results in stored time navigation/deviation if the local time is not the same as the server> Should you then feed the same data to other systems in different time zones, they will have incorrect data and it can get messy. Store the right value in the datetime field and display it as you wish as a string.