如果 UTC 时间戳可用，时区信息是否多余？

Question

我有一个简单的移动应用程序，可以在指定位置安排人们之间的未来事件。这些事件可能是物理的或虚拟的，因此为事件指定的时间可能会或可能不会与事件的“位置”处于同一时区。例如，可以在指定日期的当地时间上午 10 点在伦敦为两个人安排一次实体会议。或者，可以在指定日期的下午 4 点（在一个人的时区）为不同时区的两个人安排 Skype 通话，尽管活动的“位置”只是“办公室”，这意味着不同时区的两个不同地点。

我想知道以下设计是否适用于该应用程序：

1. 在客户端，它要求用户输入本地日期和时间，并指定事件本地的时区。

2. 在服务器上，将本地日期和时间与提供的时区转换为UTC时间戳，并仅存储此时间戳。

3. 当客户端检索这些详细信息时，它仅接收 UTC 时间戳并将其转换为与客户端当前时区相同时区的本地时间。客户端的当前时区是由当前系统时区设置决定的，我认为是根据客户端的位置自动调整的（当然，假设客户端连接到移动网络）。

我做这个设计的主要动机是：

1. UTC 是一个绝对和通用的时间标准，您可以在任何时区之间进行转换。

2. 用户只关心他们当前所在时区的本地日期和时间。

这是一个可行的设计吗？如果不是，哪些具体场景会破坏应用程序或严重影响用户体验？欢迎批评。

Answer 1

对于单个事件，知道它发生的 UTC 时刻通常就足够了，只要你有正确的 UTC 时刻（见下文）。

对于 repeated 事件，您需要知道它重复的时区...不仅是 UTC 偏移量，还有实际时区。例如，如果我安排在欧洲/伦敦与美国/洛杉矶的同事在下午 5 点每周开会，那么对于他们来说，一年中大部分会在上午 9 点举行......但是对于几个由于观察 DST 的时间不同，一年中的几周将在上午 8 点发生，一年中的几周将在上午 10 点发生。

即使对于单个事件，您也可能需要考虑如果时区规则发生变化会发生什么。假设我在 2018 年 3 月 20 日下午 4 点在欧洲/伦敦时区安排了一次会议。 目前这将在 UTC 偏移量为 0 时发生...但假设从现在到会议之间，时区规则发生变化以将英国夏令时间提前一小时。如果我在日记中将其写为下午 4 点，我可能不希望软件认为实际上是下午 5 点，因为那是我们最初预测的 UTC 时刻。

我们不知道您的确切应用程序要求，但上述情况至少为可能存储本地时间和时区而不是 UTC 时刻提供了一个论据......但你会还需要弄清楚如果本地时间由于 DST 更改而最终被跳过或不明确该怎么办。 （当时钟回退时，某些本地时间会出现两次。当时钟向前跳时，某些本地时间会被跳过。如果规则在原始计划之间发生变化，则 明确的时间可能会变得无效或不明确时间和实际事件。您可能应该在设计中考虑到这一点。）

Answer 2

为了简单起见，我的回答是：

• 如果您想定义一个时刻，时区信息是多余的。一种 UTC/Unix 时间戳完全定义了一个时刻。

• 您的设计似乎可行，但在第 2 点：我会在客户端转换为 UTC/Unix 时间戳，并且已经给出了这个时间戳 以最终形式发送到服务器。原因：客户端已经拥有转换所需的信息（参见time-keeping client-server-db architecture 示例 - 它完全基于您描述的原则）。

• 一个可能的问题（正如 Jon Skeet 在他的回答中所描述的）是重复事件，但这应该反映在您的建模方式中 时间。重复事件和固定事件之间的区别是 后者完全定义了一个时刻（如 UTC/Unix 时间戳），而第一个只是可以应用的“功能” 到当前时间获取重复的下一次触发时间 事件。但这可能与什么完全不同的问题 你问 - 无论如何，以某种方式区分重复出现 事件（如果需要）和模型中的固定事件是一个很好的选择 想法。

• 要做的一个决定是：拉还是推？或两者？您是否希望服务器能够发送电子邮件，例如，当事件发生时 经过？或者您是否只需要客户端警报 应用程序正在运行？这些问题的答案将帮助你来 走向适合您的设计。