我有一个简单的移动应用程序，可以安排指定位置的人们之间的未来事件。这些事件可能是物理事件或虚拟事件，因此为事件指定的时间可能会或可能不会与<＆＃39;位置＆＃39;处于同一时区。这件事。例如，可以在当地时间上午10点在指定日期为伦敦的两个人安排实际会议。或者，可以在指定日期的下午4点（在一个人的时区中）在不同时区的两个人安排Skype呼叫，尽管该位置可以在＆＃39;这个活动简直就是办公室＆＃39;这意味着不同时区的两个不同的地方。
我想知道以下设计适用于此应用程序：
在客户端上，它要求用户输入本地日期和时间，并指定事件的本地时区。
在服务器上，它将使用提供的时区的本地日期和时间转换为UTC时间戳，并仅存储此时间戳。
当客户端检索这些详细信息时，它仅接收UTC时间戳并将其转换为与客户端当前时区相同的时区中的本地时间。客户端的当前时区由当前系统时区设置决定，我认为这是根据客户端的位置自动调整的（当然，假设客户端连接到移动网络）。
我对这种设计的主要动机是：
UTC是一种绝对的通用时间标准，您可以从/向任何时区转换为/。
用户只关心他们当前所在时区的当地日期和时间。
这是一个可行的设计吗？如果没有，具体情况会破坏应用程序或严重影响用户体验？批评欢迎。
答案 0 :(得分：5)
对于单个事件，只要您拥有正确的UTC时刻（见下文），了解发生它的UTC时刻通常就足够了。
对于重复的事件，您需要知道它重复的时区...不仅仅是UTC偏移，而是实际时区。例如，如果我安排在欧洲/伦敦的下午5点与美国/洛杉矶的同事安排每周一次的会议，那么对于一年中的大多数它将在上午9点为他们安排...但是对于他们来说...由于观察到夏令时的差异，一年中的一周将在上午8点发生，并且在一年中的几周将发生在上午10点。
即使是单个事件，您也可以考虑如果时区规则发生变化会发生什么。假设我安排在2018年3月20日下午4点在欧洲/伦敦时区举行会议。 当前将在UTC偏移为0时发生...但是假设从现在到会议之间，时区规则会更改为在一小时之前带来英国夏令时。如果我在下午4点把它写在我的日记中，我可能不希望软件认为它实际上是在下午5点，因为这是我们最初预测的UTC时刻。
我们不知道您的确切应用程序要求，但上述情况至少为可能存储本地时间和时区而非UTC时刻提供了一个参数......但是您和＃39; ll 还需要弄清楚如果由于DST更改导致本地时间被跳过或模糊不清，该怎么办。 （当时钟回落时，某些本地时间会出现两次。当时钟向前跳过时，会跳过一些本地时间。如果规则在原始规划之间发生变化，那么 明确的时间可能会变得无效或模棱两可时间和实际事件。您应该在设计中考虑到这一点。）
答案 1 :(得分：1)
为了简单起见，我的答案是：
您的设计似乎可行，但在第2点：我会转换为客户端的UTC / Unix时间戳并已经给出了这个时间戳 以最终形式发送到服务器。原因：客户端已经拥有转换所需的信息（请参阅此time-keeping client-server-db architecture 例如 - 它完全基于您描述的原则。
一个可能的问题（正如Jon Skeet在他的回答中所描述的）是反复发生的事件，但这应该反映在你建模的方式中 时间。重复事件和固定事件之间的区别是 后者完全定义了一个时刻（如UTC / Unix） 时间戳），而第一个只是一个可以应用的“功能” 到当前时间以获得重复的下一个触发时间 事件。但这可能完全是一个不同的问题 你问 - 无论如何，以某种方式区分反复出现 事件（如果你需要它们）和模型中的固定事件是一件好事 想法。
做出的决定是：PULL还是PUSH？或两者？您是否希望服务器能够在事件发生时发送电子邮件 通过？或者您只想在客户端进行客户端警报 应用正在运行？这些问题的答案将帮助您 朝着适合你的设计。