存储事件时，UTC会在DST时发出问题。

Question

我在问这个之前就找了这个，但是找不到任何有用的东西。我有一个使用UTC的服务器，客户端可以设置服务器每天执行的事件的时间(这是一个简化)。例如，法国有人希望在当地时间23:00 (世界协调时22:00)发生一个事件。我将它转换为UTC并存储它；服务器每天22:00愉快地执行。然后到了夏天，现在法国的偏移量是+2h，服务器仍然在22:00 UTC执行，但是对于用户来说这是错误的时间，因为22:00UTC在法国现在是当地时间00:00。

我存储在UTC，因为每个人都说要存储在UTC，并在输出给用户时转换为本地时间，很好，但这并不像用户期望的那样工作。我想我应该存储大约23:00的法国时间，服务器应该使用它，然后说"ok，这是今天22:00的世界协调时间“或ok，这是今天21:00的世界协调时间，因为我使用的是JodaTime BTW)，但是这与每个人关于我应该如何将它存储在DB...so...what can/应该做的事情上的说法相矛盾吗？

如果我用偏移量存储本地时间和日期，并且当我读取它(在使用UTC的服务器上)时，我会这样做：

DateTime dbLocalHistoricDateTime = fromDB(); // suppose this 23:00 in France on the 01.01.2015 (UTC+1), 22:00 UTC on that date
DateTimeZone localZone = dbLocalHistoricDateTime.getZone();
DateTime currentLocalDateTime = DateTime.now().withZone(localZone);
DateTime localToday = dbLocalHistoricDateTime.withDate(currentLocalDateTime.getYear(), currentLocalDateTime.getMonthOfYear(), currentLocalDateTime.getDayOfMonth());
DateTime utcToday = localToday.withZone(DateTimeZone.UTC);

然后utcToday包含了今天正确的UTC时间(21:00UTC是27.04.2015在法国的23:00 )，然后服务器可以在UTC时间上执行这个事件。

谢谢加布里埃尔

Answer 1

如果要表示重复事件，则肯定需要存储本地时间和时区，并在时间变得无效或不明确时存储或决定该策略。(假设用户存储02:30 --在春天，当时钟向前移动时，这个值根本不会出现，而在秋天，当时钟倒转时，这个值会发生两次。)

但是，如果您有重复事件，则可能不应该存储DateTime --我会存储类似“开始日期”(应该发生的第一个日期；LocalDate)、每天应该发生的时间( LocalTime)和时区ID (例如Europe/Paris)之类的内容。

如果要存储未来的事件，存储“本地日期/时间和时区”也是很重要的，请记住时区规则可能在时差和时差之间发生变化。

在以下情况下，存储UTC即时记录是有用的：

• 原来的时区不再相关(如果它甚至存在的话)
• 这个事件不会重复
• 你想要能够很容易地比较事件

这与时间戳特别相关。

但是是的，就像大多数的日期/时间处理一样，一个简单的“一刀切”的答案是不存在的--你需要考虑你的上下文。