0

我知道我们应该在我们的数据库中以 UTC 格式存储时间，但是由于以下原因，我很难从我的团队那里获得支持来采用它：

  • 我们从不处理内部时间戳
  • 我们有夏令时，但我们总是显示本地时间，无需以 UTC 存储
  • 由于现在需要转换，因此数据磨损室的负担很大
  • 我们使用外部数据并且它们不是UTC，这会给其他人带来额外的工作
  • 我们的业务用户从未问过

我在这里有两个问题。

  • 如果我们将现有的本地时间转换为 UTC，那是否总是会产生有效的日期时间戳？我听说从 UTC 到当地时间的转换总是有效的。但是从本地时间转换为 UTC 可能不会。
  • 我想不出任何其他支持 UTC 的论点，除非这是正确的做法并且 UTC 时间始终有效。

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

4

2 回答 2

4

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

定义“有效”。

一方面，它并不总是明确的。给定的本地时间可以映射到 0、1 或 2 个 UTC 时间：

  • 如果跳过本地时间，则为 0 个映射，例如，由于 DST 转换“向前跳”，本地时间从凌晨 1 点变为凌晨 2 点时为 1.30。当然，如果它应该是有效的当地时间，则不应该发生这种情况，但如果您有类似每周活动的活动，您可能会无意中得到无效的当地时间。
  • 如果不涉及 DST 转换，则为 1 个映射
  • 如果当地时间不明确，则为 2 个映射，例如，由于 DST 转换“回退”，当地时间从凌晨 2 点回到凌晨 1 点时为 1.30

从根本上说，当您需要考虑 DST 转换时，本地时间更难推断。例如，12.30am + 1 小时并不总是 1.30am。

就我个人而言，我认为您应该尝试对您真正代表的时间进行建模。有时这是与 UTC 有特定偏移的当地时间；有时它根本不是人类时间，而是具有任意比例和时代的时间戳。我在Noda Time 用户指南中写了一些关于此的内容。

你还没有真正告诉我们你需要在这些时间做什么。你需要执行任何类型的算术吗？比较？复发？向用户展示？可能向其他时区的用户显示？如果没有这类信息，很难提出任何具体的建议。

于 2012-06-08T22:13:37.433 回答
1

将时间存储为 UTC 是最安全的方法。如果您想存储本地时间，您可以这样做，如果您还存储 UTC 偏移量 (2012-05-20 05:34 UTC−06:00)。

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

通常人们倾向于认为时区是地理定义的，但我们的时区与 DST 切换。例如，欧洲在冬季使用中欧时间 (CET)，在夏季使用中欧夏令时 (CEST)。纳米比亚与欧洲在同一经度上，它们看起来使用相同的时区并且都使用 DST。但是纳米比亚和欧洲永远不会有相同的当地时间，因为纳米比亚在南边，反之亦然。

于 2013-09-27T14:32:50.890 回答