I'm hoping to convert a table which has a DATETIMEOFFSET
field, down to a DATETIME
field BUT recalculates the time by taking notice of the offset. This, in effect, converts the value to UTC
.
eg.
CreatedOn: 2008-12-19 17:30:09.0000000 +11:00
that will get converted to
CreatedOn: 2008-12-19 06:30:09.0000000
or
CreatedOn: 2008-12-19 06:30:09.0000000 + 00:00 -- that's a `DATETIMEOFFSET`, but `UTC`.
Cheers :)
7条答案
按热度按时间hkmswyz61#
Converting using almost any style will cause the datetime2 value to be converted to UTC.
Also, conversion from datetime2 to datetimeoffset simply sets the offset at
+00:00
, per the below, so it is a quick way to convert fromDatetimeoffset(offset!=0)
toDatetimeoffset(+00:00)
qrjkbowd2#
I'd use the built in SQL option:
col17t5w3#
I know this is an old question but, if you want to convert DateTimeOffset to a DateTime, I think you need to take into account the timezone of the server you are converting on. If you just do a CONVERT(datetime, @MyDate, 1) you will simply lose the time zone, which likely results in an incorrect conversion.
I think you first need to switch the offset of the DateTimeOffset value, then do the conversion.
The result of converting '2013-11-21 00:00:00.0000000 -00:00' to a DateTime on a server who's offset is -7:00 will be 2013-11-20 17:00:00.000. With the above logic it doesn't mater what the time zone of the server or the offset of the DateTime value, it will be converted to DateTime in the servers time zone.
I believe you need to do this because a DateTime value includes an assumption that the value is in the time zone of the server.
li9yvcax4#
DateTimeoffset (Timezone) conversion in SQL Server.
SQL Server 2016 (13.x) and later
Exmample
Result will be
6gpjuf905#
Note: The timezone information is discarded in conversion if no style ("126" here) is specified. It might also be discarded in some of the other styles, I don't know -- in any case the following correctly adjusts for the TZ information. See CAST and CONVERT .
Happy SQL'ing.
Edit
Not sure if it matters but ...
datetime
Can't actually store that level of precision/accuracy. If the above is run the fractional seconds will be truncated to 3 digits (and accuracy is less than that). The same-same withdatetime2
(anddatetimeoffset(7)
) produces a non-truncated value:bbmckpt76#
Several ways of converting from
DateTimeOffset
toDateTime2
(UTC or local).On SQL Server 2019:
pxyaymoc7#
In order to account for daylight savings time, I used the following:
Note:
time_stamp_end_of_interval
is a varchar