是时区信息冗余，只要UTC时间戳可用吗？ [英] Is timezone info redundant provided that UTC timestamp is available?

问题描述

我有一个简单的移动应用程序，用于在指定位置的人员之间安排未来事件。这些事件可能是物理的或虚拟的，所以指定事件的时间可能与也可能不在与事件的位置相同的时区。例如，可以在当地时间上午10点在指定的日期为伦敦的两个人举行实体会议。或者，可以在指定日期的下午4点（在一个人的时区）为不同时区的两个人安排Skype电话，但事件的位置只是办公室，这意味着不同时区的两个不同的地方。 p>

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

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




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




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

我的主要动机是：

1. UTC是一个绝对和世界的时间标准，您可以从/转换到任何时区。




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

这是一个可行的设计吗？如果没有，什么具体情况会打破应用程序或严重影响用户体验？批评欢迎。

解决方案

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

对于重复的事件，您需要知道它重复的时区...不只是UTC偏移，但实际的时区。例如，如果我在欧洲/伦敦的下午5点在美国/ Los_Angeles的同事安排一次每周一次的会议，那么在今年的大部分时间里，他们将在上午9点发生，但是对于一些一年中的星期将在上午8点发生，并在一年的几周内将在上午10点发生，因为观察到DST时的差异。

即使一个事件，你可能会考虑如果时区规则改变会发生什么。假设我在2018年3月20日下午4点在欧洲/伦敦时区安排会议。目前将以UTC偏移0 ...发生，但假设从现在开始和会议之间，时区规则将更改为在一小时之内带来英国夏令时间。如果我在下午4点写在我的日记中，我可能不希望软件认为它实际上是在下午5点，因为这是我们原来预测的UTC时刻。

我们不知道您的确切应用程序要求，但上述情况至少为可能存在本地时区和时区（而不是UTC时刻）提供参数，但您将 >也需要解决如果当地时间由于DST更改而被跳过或模糊不清，该怎么办。 （当时钟倒退时，一些本地时间发生两次，当时钟跳过时，跳过一些本地时间，如果规则在原始规划之间变化，那么 明确的时间可能会变得无效或模糊时间和实际事件，您应该在设计中解释这一点。）

I have a simple mobile app that schedules future events between people at a specified location. These events may be physical or virtual, so the time specified for the event may or may not be in the same timezone as the 'location' of the event. For example, a physical meeting may be scheduled for two people in London at local time 10am on a specified date. Alternatively, a Skype call may be scheduled for two people in different timezones at 4pm (in one person's timezone) on a specified date though the 'location' of the event is simply 'office' which means two different places in different timezones.

I wonder the following design is going to work for this application:

1. On the client, it asks user to input the local date and time and specify the timezone local to the event.

2. On the server, it converts the local date and time with the provided timezone into UTC timestamp, and store this timestamp only.

3. When a client retrieves these details, it receives the UTC timestamp only and converts it into local time in the same timezone as the client's current timezone. The client's current timezone is determined by the current system timezone setting, which I think is automatically adjusted based on the client's location (of course, assuming the client is connected to a mobile network).

My main motivations for this design are:

1. UTC is an absolute and universal time standard, and you can convert to/from it from/to any timezone.

2. Users only care about the local date and time in the timezone they are currently in.

Is this a feasible design? If not, what specific scenarios would break the application or severely affect user experience? Critiques welcome.

解决方案

For a single event, knowing the UTC instant on which it occurs is usually enough, so long as you have the right UTC instant (see later).

For repeated events, you need to know the time zone in which it repeats... not just the UTC offset, but the actual time zone. For example, if I schedule a weekly meeting at 5pm in Europe/London with colleagues in America/Los_Angeles, then for most of the year it will occur at 9am for them... but for a couple of weeks in the year it will occur at 8am and for a couple of weeks in the year it will occur at 10am, due to differences in when DST is observed.

Even for a single event, you might want to consider what happens if time zone rules change. Suppose I schedule a meeting for 4pm on March 20th 2018, in the Europe/London time zone. Currently that will occur with a UTC offset of 0... but suppose between now and the meeting, the time zone rules change to bring British Summer Time in one hour earlier. If I've written it in my diary as 4pm, I probably don't want the software to think that it's actually at 5pm because that's the UTC instant we originally predicted.

We don't know your exact application requirements, but the above situations at least provide an argument for potentially storing the local time and time zone instead of the UTC instant... but you'll also need to work out what to do if the local time ends up being skipped or being ambiguous due to DST changes. (When the clocks fall back, some local times occur twice. When the clocks skip forward, some local times are skipped. A time that was unambiguous may become invalid or ambiguous if the rules change between the original planning time and the actual event. You should probably account for this in your design.)

这篇关于是时区信息冗余，只要UTC时间戳可用吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！