-1

我的公司正在支持美国客户的以下应用程序：

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

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

谢谢，维沙赫

4

1 回答 1

0

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

  • 夏令时的一天有 23 或 25 小时，而不是像往常一样的 24 小时
  • 02:00h 和 03:00h 之间有间隔，或者这些时间出现两次

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

如果它们在时区更改中正常工作，您可能应该检查您使用的产品/库。

我测试了我们的 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那样，它可以正常工作，但是有很多库和产品都失败了。

于 2009-02-26T14:22:28.857 回答