我们正在将应用程序迁移到Azure,但是当前所有日期都存储为东部标准时间。由于SQL Azure在UTC上,并且我们的许多日期都是通过getdate()调用生成的,因此,如果我们将所有内容保持原样,都会遇到问题。看来,最不会造成长期困扰的选项是将所有存储的日期都转换为UTC,并在前端将其转换为本地时间。
不幸的是,似乎没有内置的方法可以将SQL日期时间从一个时区转换为另一个时区,而我发现的许多解决方案都没有考虑夏令时。我发现确实考虑DST的解决方案涉及导入日历和时区表,并且非常复杂。
我只是在寻找可以一次转换的东西,而且不一定漂亮。有任何想法吗?
更新:我编写了以下函数,我相信它将完成我所需要的。有人看到这个有漏洞吗?我目前所有的日期均为东部标准时间,但我的日期始于2002年左右,所以我不得不在2007年处理该法律变更。
我在想我会像这样使用此功能:
UPDATE myTable SET myDate = dbo.fnESTtoUTC(myDate)
功能如下:
CREATE FUNCTION [dbo].[fnESTtoUTC]
(@pESTDate DATETIME)
RETURNS DATETIME
AS
BEGIN
DECLARE @TimeZoneOffset INT
DECLARE @Year INT
DECLARE @Day INT
DECLARE @DSTStart DATETIME
DECLARE @DSTEnd DATETIME
SELECT @Year = DATEPART(year, @pESTDate)
IF @Year >= 2007
BEGIN
SELECT @Day = 8
WHILE @DSTStart IS NULL
BEGIN
-- Second Sunday in March
IF DATEPART(weekday, DATEFROMPARTS(@Year, 3, @Day)) = 1
SELECT @DSTStart = DATETIMEFROMPARTS(@Year, 3, @Day, 2, 0, 0, 0)
SELECT @Day = @Day + 1
END
SELECT @Day = 1
WHILE @DSTEnd IS NULL
BEGIN
-- First Sunday in November
IF DATEPART(weekday, DATEFROMPARTS(@Year, 11, @Day)) = 1
SELECT @DSTEnd = DATETIMEFROMPARTS(@Year, 11, @Day, 1, 0, 0, 0)
SELECT @Day = @Day + 1
END
END
ELSE
BEGIN
SELECT @Day = 1
WHILE @DSTStart IS NULL
BEGIN
-- First Sunday in April
IF DATEPART(weekday, DATEFROMPARTS(@Year, 4, @Day)) = 1
SELECT @DSTStart = DATETIMEFROMPARTS(@Year, 4, @Day, 2, 0, 0, 0)
SELECT @Day = @Day + 1
END
SELECT @Day = 31
WHILE @DSTEnd IS NULL
BEGIN
-- Last Sunday in October
IF DATEPART(weekday, DATEFROMPARTS(@Year, 10, @Day)) = 1
SELECT @DSTEnd = DATETIMEFROMPARTS(@Year, 10, @Day, 1, 0, 0, 0)
SELECT @Day = @Day - 1
END
END
IF @pESTDate >= @DSTStart AND @pESTDate < @DSTEnd
BEGIN
-- Date is in DST
SELECT @TimeZoneOffset = 4
END
ELSE
BEGIN
-- Not DST
SELECT @TimeZoneOffset = 5
END
RETURN ( dateadd(hh, @TimeZoneOffset, @pESTDate) )
END
有几个问题:
您将基于当前使用的规则,而不是输入中提供的日期。您应该确定要更改它。
如果我传递诸如2013-03-10 02:30之类的值,则您的函数将假定它为EDT,但实际上时间是无效的,并且不应存在于您的数据中。您可能应该提出一个错误。
如果我通过这样的值,2013年11月3日01:30,你的函数会认为它是EDT,但在现实中,它可能是在任何EDT或EST。您可能需要存储offset或dst标志才能消除歧义。如果不在数据中,则别无选择,只能假设其中一个。
此功能不考虑1987年之前的日期,该日期在美国也有DST规则更改。如果您有之前的数据,则也应考虑这一点。
除此之外,它看起来还不错。不过,评论中的观点是正确的。这仅适用于该时区,并且您不能保证此时区的规则将来不会更改。我建议您以后使用转换数据以使用UTC。您可以根据需要使用此函数进行转换,也可以在应用程序级代码中轻松进行此转换。
哦,还有另一件事。“东部标准时间”或“ EST”字面意思是UTC-5,完全不考虑夏令时。就像“东部夏令时间”或“ EDT”一样,始终表示UTC-4。我假设您的意思是说您的数据在问题的“东部时间”中,可以同时容纳这两者。
如果您实际上是指EST,那么您的工作就简单得多-只需增加5个小时并称其完成即可。之所以提出这一点,是因为确实存在一些场景,其中记录的数据与夏时制无关。(我相信在金融行业中有一些用例可以像这样工作。)
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句