UTC和当地时间是否可以在节省日光的地方互换？

Question

我知道我们应该在UTC中存储数据库中的时间，但由于以下原因，我很难获得团队的支持：

• 我们从不处理内部时间戳
• 我们节省了一天，但我们始终显示本地时间，无需以UTC格式存储
• 由于现在需要转换，因此数据服务器的负担很大
• 我们使用外部数据但它们不是UTC，它会为其他人带来额外的工作
• 我们的商业用户从未问过

我在这里有两个问题。

• 如果我们将现有的本地时间转换为UTC，那总是会产生有效的日期时间戳吗？我听说从UTC到本地时间的转换始终有效。但是从本地时间到UTC的转换可能不会。
• 我想不出任何其他专业的UTC参数，除非它是正确的事情，UTC时间总是有效的。

对于大多数用法，这些时间将用于显示目的，并且还运行报告aganist（开始日期和结束日期）。一些商业用户也可以直接读取它们（他们喜欢当地时间）。

Answer 1

  

如果我们将现有的本地时间转换为UTC，那是否是有效的转换？

定义＆＃34;有效＆＃34;。

一方面，它并不总是毫不含糊。给定的本地时间可以映射到0,1或2 UTC时间：

如果跳过本地时间，则
• 0映射，例如1.30当地时间从早上1点到凌晨2点，由于DST过渡＆＃34;向前弹＆＃34;。当然，如果它意味着有效当地时间，则不应该发生这种情况，但是如果您有类似每周活动的事情，那么无意中可能会导致无效的当地时间
• 1映射，如果没有涉及DST转换
如果当地时间不明确，则
• 2映射，例如1.30当地时间从早上2点回到凌晨1点，由于DST过渡而退回＆＃34;

从根本上说，当您需要考虑DST过渡时，当地时间更难以推理。例如，上午12点30分+ 1小时不总是凌晨1点半。

就我个人而言，我认为你应该尝试模拟真正所代表的任何时间。有时是当地时间与UTC的特定偏差;有时它根本不是一个人类时间，而是一个具有任意比例和时代的时间戳。我在Noda Time user guide。

中写了一些关于此的内容

在这些时候，您还没有告诉我们做所需的内容。你需要进行任何算术吗？比较？复发？向用户显示？可能会向其他时区的用户显示？没有这类信息，很难提出任何具体的建议。

Answer 2

将时间存储为UTC是最安全的方式。如果你想存储当地时间，你也可以存储UTC偏移量（2012-05-20 05:34 UTC-06：00）。

现在我评论的神奇中心句子是：“时区是UTC偏移！”

人们往往认为时区是地理定义的，但我们的时区会使用DST切换。 例如，欧洲在冬季使用中欧时间（CET），在夏季使用中欧夏令时（CEST）。纳米比亚与欧洲的经度相同，它们看起来像使用相同的时区，都使用夏令时。但纳米比亚和欧洲将永远不会有相同的当地时间，因为纳米比亚位于南侧，反之亦然。