我知道我们应该在数据库中以UTC格式存储时间，但是由于以下原因，我很难获得团队的支持来采用它：
- 我们从不处理内部时间戳
- 我们有夏令时，但我们始终显示当地时间，无需以 UTC 格式存储
- 数据磨损的负担是巨大的，因为现在需要转换
- 我们使用外部数据，而它们不在UTC中，这会给其他人带来额外的工作
- 我们的业务用户从未问过
我这里有两个问题。
- 如果我们将现有的本地时间转换为 UTC，这是否始终会产生有效的日期时间戳？我听说从UTC到当地时间的转换总是有效的。但从本地时间转换为 UTC 可能不会。
- 我想不出任何其他专业的 UTC 参数，除非这是正确的做法并且 UTC 时间始终有效。
对于大多数使用情况，这些时间将用于显示目的，并针对（开始日期和结束日期）运行报告。一些业务用户也可以直接读取它们（他们喜欢本地时间）。
如果我们将现有的本地时间转换为 UTC，这是有效的转换吗？
定义"有效"。
一方面，它并不总是明确的。给定的本地时间可以映射到 0、1 或 2 UTC 时间：
- 如果跳过本地时间，则为 0 个映射，例如，当由于 DST 转换"弹簧前进"，当地时间从凌晨 1 点变为凌晨 2 点时为 1.30。当然，如果它应该是有效的本地时间，则不应该发生这种情况，但是如果您有类似每周事件之类的事情，则可能会无意中得到无效的本地时间。
- 1 个映射（如果未涉及 DST 转换）
- 如果本地时间不明确，则为 2 个映射，例如，由于 DST 转换"回退"，当地时间从凌晨 2 点回到凌晨 1 点，则为 1.30
从根本上说，本地时间很难推理何时需要考虑 DST 转换。 例如，上午 12：30 + 1 小时并不总是凌晨 1：30。
就我个人而言，我认为你应该尝试模拟你所得到的时代真正代表的东西。有时这是本地时间，与 UTC 有特定的偏移量;有时它真的根本不是人类的时间，而是一个具有任意比例和纪元的时间戳。我在野田时间用户指南中写了一些关于这个的内容。
你还没有真正告诉我们你需要在这些时间做些什么。您需要执行任何类型的算术吗？比较？复发？向用户显示？可能向其他时区的用户显示？没有这种信息，很难提出任何具体的建议。
将
时间存储为 UTC 是最安全的方法。如果要存储本地时间，可以这样做，如果您还存储 UTC 偏移量 （2012-05-20 05：34 UTC−06：00）。
现在我的评论的神奇中心句："时区是UTC偏移量！
通常人们倾向于认为时区是地理定义的，但我们的时区会随着夏令时而切换。例如，欧洲在冬季使用中欧时间 （CET），在夏季使用中欧夏令时 （CEST）。纳米比亚与欧洲在同一经度上，它们看起来像使用相同的时区，并且都使用夏令时。但纳米比亚和欧洲永远不会有相同的当地时间，因为纳米比亚在南侧，反之亦然。