Question

我的公司正在为美国客户提供以下申请：

IBM大型机，DB2 ，Unix ，Teradata ，甲骨文，SQL Server 2005 ，劳森

由于夏令时将在下个月开始，我想知道您对我们应该注意什么的一般想法，以便我们可以避免任何不良事件？

谢谢， Visakh

Answer 1

夏令时可能有点棘手，有些想法：

夏令时的日子是23或25小时，而不是通常的24小时
在02：00h和03：00h之间有一个间隙或这些时间出现两次

当您从外部获取数据时，您必须始终使用时区，否则，您将遇到问题。例如。您无法知道发件人是否已经更改了夏令时设置，因为您无法可靠地知道设备上是否一切正常，此外，大多数用户不会更改时区（或夏令时标志），他们会更改时间本身，这将使你遇到严重的麻烦。手机有时不会自行更改日光设置，用户更改只需将时间从02：00h更改为03：00h CET！这显然是错的，因为时间本身并没有改变，这是时区！它仍然是欧洲中部时间02：00h，但是在03：00h CEST。

如果正确使用时区更改，您应该检查所使用的产品/库。

我测试了我们的python（使用mx.DateTime）环境，如果它正确知道要使用的时区：

测试程序：

from mx.DateTime import *

def f(dt):
    return dt.Format("%Y-%m-%d %H:%M %Z")

base = ISO.ParseDateTime('2009-03-29 00:00')

for i in range(10):
    test = base + i*(30*oneMinute)
    diff = test.ticks()-base.ticks()

    print "Seconds between %s and %s: %d(%d) diff=%d" % (f(base),
                                                         f(test), diff,
                                                     i*1800, i*1800-diff)

输出给我（生活在德国，3月29日是夏令时）：

$ python test.py
Seconds between 2009-03-29 00:00 CET and 2009-03-29 00:00 CET: 0(0) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 00:30 CET: 1800(1800) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 01:00 CET: 3600(3600) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 01:30 CET: 5400(5400) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 02:00 CEST: 7200(7200) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 02:30 CEST: 9000(9000) diff=0
Seconds between 2009-03-29 00:00 CET and 2009-03-29 03:00 CEST: 7200(10800) diff=3600
Seconds between 2009-03-29 00:00 CET and 2009-03-29 03:30 CEST: 9000(12600) diff=3600
Seconds between 2009-03-29 00:00 CET and 2009-03-29 04:00 CEST: 10800(14400) diff=3600
Seconds between 2009-03-29 00:00 CET and 2009-03-29 04:30 CEST: 12600(16200) diff=3600

正如您所看到的mx.DateTime工作正常，但有很多库和产品失败。

在夏令时开始之前，我需要在支持环境中做些什么？

1 个答案: