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

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

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

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

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

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

我进行此设计的主要动机是：

UTC是一种绝对的世界时标准，您可以在任何时区之间转换为UTC

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

---

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

对于单个事件，了解事件发生的UTC时间通常就足够了，只要您拥有正确的UTC时间（见下文）

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

即使是单个事件，也可能要考虑时区规则更改时会发生什么。假设我安排2018年3月20日下午4点在欧洲/伦敦时区开会。当前，将在UTC偏移量为0时发生。。。但假设从现在到会议期间，时区规则发生变化，使英国夏季时间提前一小时。如果我把它写在我的日记中是下午4点，我可能不想让软件认为它实际上是下午5点，因为那是我们最初预测的UTC时间

---

我们不知道您的确切应用程序要求，但上述情况至少为可能存储本地时间和时区而不是UTC瞬变时间提供了依据。。。但是，如果由于DST更改而导致本地时间被跳过或不明确，您还需要确定该怎么办。（当时钟倒转时，某些本地时间会出现两次。当时钟向前跳时，某些本地时间会被跳过。如果规则在原始计划时间和实际事件之间发生变化，则明确的时间可能会变得无效或不明确。您可能应该在设计中对此进行说明。）

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

• 如果要定义单个时刻，则时区信息是多余的。A. UTC/Unix时间戳完全定义了一个时刻
• 您的设计似乎是可行的，但在第2点：我将在客户端转换为UTC/Unix时间戳，并且已经给出了这个时间戳 以其最终形式发送到服务器。原因：客户端已经具有转换所需的信息（请参见此 示例-它完全基于您描述的原则工作）

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

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