Is timezone info redundant provided that UTC timestamp is available?
我有一个简单的移动应用程序，它可以在指定地点的人之间安排未来的活动。这些事件可能是物理的或虚拟的，因此为事件指定的时间可能与事件的"位置"在同一时区内，也可能不在同一时区内。例如，可以在指定日期当地时间上午10点在伦敦安排两人的物理会议。或者，可以在指定日期下午4点(在一个人的时区内)为两个位于不同时区的人安排Skype呼叫，尽管活动的"地点"只是"办公室"，这意味着在不同时区有两个不同的地点。
我想知道以下设计是否适用于此应用程序：
在客户机上，它要求用户输入本地日期和时间，并指定事件的本地时区。
在服务器上，它使用提供的时区将本地日期和时间转换为UTC时间戳，并仅存储此时间戳。
当客户机检索这些详细信息时，它只接收UTC时间戳，并将其转换为与客户机当前时区在同一时区内的本地时间。客户机的当前时区由当前的系统时区设置决定，我认为它是根据客户机的位置自动调整的(当然，假设客户机连接到移动网络)。
我的主要动机是：
UTC是一个绝对和通用的时间标准，您可以从它转换到/从它转换到任何时区。
用户只关心当前所在时区的本地日期和时间。
这是可行的设计吗？如果没有，什么特定的场景会破坏应用程序或严重影响用户体验？欢迎批评。
对于单个事件，只要您有正确的UTC时间(见下文)，知道它发生的UTC时间通常就足够了。
对于重复事件，您需要知道它重复的时区…不仅是UTC偏移量，还包括实际时区。例如，如果我在欧洲/伦敦和美国/洛杉矶的同事安排一个周会，那么在一年中的大部分时间里，他们都会在上午9点举行……但在一年中的几周内，由于观察DST的时间不同，将在上午8点发生，在一年中的几周内，将在上午10点发生。
即使对于单个事件，您也可能需要考虑如果时区规则发生更改会发生什么。假设我计划在2018年3月20日下午4点在欧洲/伦敦时区举行会议。当前将以0的UTC偏移量发生…但假设从现在到会议期间，时区规则改变，使英国的夏季时间提前一小时。如果我把它写在我的日记中，作为下午4点，我可能不希望软件认为它实际上是下午5点，因为那是我们最初预测的UTC时刻。
我们不知道您的确切应用程序要求，但上述情况至少为存储本地时间和时区(而不是UTC即时)提供了一个论据…但是，如果由于DST更改而导致本地时间被跳过或不明确，您还需要计算出要做什么。(当时钟倒转时，一些本地时间会出现两次。当时钟向前跳时，会跳过一些本地时间。如果规则在原始计划时间和实际事件之间发生更改，则明确的时间可能会变得无效或不明确。您可能应该在设计中考虑到这一点。)
为了简单起见，我的答案是：
- 如果您想定义一个时刻，时区信息是多余的。一UTC/Unix时间戳完全定义了一个时刻。
您的设计似乎可行，但在第2点上：我将在客户端转换为UTC/Unix时间戳，并且已经给出了这个时间戳以其最终形式发送给服务器。原因：客户端已经具有转换所需的信息(请参见本次保留客户端服务器数据库建筑学示例-它完全基于您描述的原则工作)。
一个可能的问题(如jon skeet在他的答案中所描述的)是重复发生的事件，但这应该反映在您建模的方式中。时间。重复事件和固定事件的区别在于后者完全定义了一个时刻(如UTC/Unixtimestamp)而第一个只是可以应用的"函数"到当前时间，以获取循环的下一个触发时间事件。但这可能是一个完全不同于你问——无论如何，在某种程度上，区分重复出现的事件(如果需要)和模型中的固定事件想法。
要做的一个决定是：拉还是推？还是两者兼而有之？您希望服务器能够发送电子邮件吗，例如，当事件发生时通过？或者只在客户端应用程序正在运行？这些问题的答案将帮助你来适合你的设计。