是否有充分的理由不使用 UTC 存储时间？
我想知道是否有任何充分的理由以 UTC (GMT) 以外的任何时间存储时间信息？ 我相信这是所有软件工程的坚实规则。 转换为本地时间只是出于显示目的而在 UI 层发生的转换。 我还见过需要翻译才能正确实现算法的情况（用于处理午夜日期更改等）。
I am wondering if there are any good reasons to ever store time information in anything other that UTC (GMT)? I believe that this is a solid rule for all software engineering. The conversion to local time is merely a translation that happens at the UI layer for display purposes. I have also seen cases where the translatation is needed in order to implement an algorithm correctly (for handling midnight date changes, etc.).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
一般来说，我发现使用 UTC 更好。
有时您可能需要当地时间。 那么我宁愿使用 UTC + 时区信息。
一般来说，重复事件可能非常棘手，您应该非常仔细地分析用例。
想象一下每周二上午 9:00 举行的定期会议。
如果 DST 发生变化，会议仍应在（新的）上午 9:00 举行。
但没有增加在法国的一些人的会议。 对于他们来说，会议时间为下午 6:00。
他们通过不同的规则更改夏令时。
当你更改夏令时时，他们不会，所以在一段时间内（直到法国更改夏令时）有人应该“休息”：要么你的会议在上午 10 点举行，而他们的会议将在下午 6 点举行，要么你的会议在上午 9 点举行，而他们的会议则移至上午 9 点下午 5 点。 没有别的办法，电脑与此无关。
应用程序将如何决定谁应该被“修复”？
是成员最多的团体吗？ （美国 1 个人 vs 法国 20 个人？）还是与这个人的重要性有关？ （如果美国的第一个人是首席执行官怎么办？）
您如何存储这些信息？
我最好的解决方案是使用 UTC + 一个“主时区”
“主时区”中的用户获胜（保持固定）。
事情可能会变得相当棘手，但总的来说，我发现 UTC 解决的问题比它引入的问题多。
为了澄清 fjsj 的一个（非常有效的:-）观点：“主时区”我指的是确切的区域，包括有关 DST 是否有效的信息。
如果您只存储
PT（太平洋时间），那么这是不够的。PST（太平洋标准时间）或PDT（太平洋夏令时间）。也许更好的是不要将定期会议视为“固定时间点”，以“纪元”中的秒/毫秒表示。 编程语言（终于）开始采用 JodaTime 的概念。
In general it I find it better to use UTC.
Sometimes you might need a local time. Then I would rather go with UTC + timezone information.
In general times can be extremely tricky for repetitive events, and you should very carefully analyze the use cases.
Imagine a recurring meeting, every Tuesday at 9:00 am.
If the DST changes, the meeting should still happen at (the new) 9:00am.
But no add to the meeting some guys in France. For them the meeting is at 6:00pm.
And they change the DST by a different rule.
When you change the DST, they don't, so for a while (until France changes DST) someone should be "off": either your meeting will be at 10am that theirs will stay at 6pm, or keep yours at 9am and move theirs at 5pm. There is no other way, computers have nothing to do with it.
How will an application decide who should be "fixed"?
Is it the group with most members? (1 guy in US vs 20 in France?) Or is it about the importance of the person? (what if the 1 guy in US is the CEO?)
How do you store that info?
My best solution is to use UTC + one "master time zone"
The users in the "master time zone" win (stay fixed).
Things can get pretty tricky, but in general I have found the UTC solves more problems than it introduces.
To clarify a (very valid :-) point from
fjsj: by "master time zone" I mean the exact zone, including the info about DST active or not.If you just store
PT(Pacific Time), then it is not enough.PST(Pacific Standard Time) orPDT(Pacific Daylight Time) is.Probably even better is not not think of recurring meetings as "a fixed point in time" expressed in seconds / milliseconds from the "epoch". Programming languages have (finally) started to adopt concepts from JodaTime.
我想说这取决于应用程序。 我研究电离层和电离层的空间物理模型。 磁层。 我们使用磁性当地时间、存储日期和时间。 时间为修改后的儒略日。
I'd say it's application-dependent. I work on space physics models of the Ionosphere & Magnetosphere. We work with magnetic local time, storing date & times as Modified Julian Days.
警报和 计划任务有时会按当地时间存储，以便不受夏令时或时区更改的影响。
Alarms & scheduled tasks are sometimes stored in local time so that they aren't affected by Daylight Saving Time or timezone changes.
UTC 是一种计时标准，其准确度和精度为 TAI，但以不规则的间隔添加闰秒，以使其能够密切跟踪平均太阳时 (UT1)。
如果您使用的系统无法处理闰秒，则Bureau International des Poids et Mesures建议使用 TAI 而不是 UTC。
请参阅：http://tycho.usno.navy.mil/leapsec.html
UTC is a time-keeping standard that has the accuracy and precision of TAI, but with leap seconds added in at irregular intervals to allow it to closely track mean solar time (UT1).
If the system that you are working with cannot handle leap seconds, then the Bureau International des Poids et Mesures recommends that TAI be used instead of UTC.
See: http://tycho.usno.navy.mil/leapsec.html
曾经吗？ 我确信在某些孤立的案例中是有充分理由的。 不过，一般来说，存储 UTC 比存储本地时间要好得多，因此除非有特殊考虑，否则我会将 UTC 视为默认位置。
Ever? I'm sure there are good reasons in some isolated cases. In general, though, storing UTC is much better than local time, so I would treat UTC as the default position unless there's some special consideration.
在嵌入式系统中，您很可能会以某种“过去的纪元”形式从源接收时间。
如果时间更新相对频繁，并且显示相对不频繁，那么您不妨以提供给您的相同方式存储它，并且仅在需要时将其转换为显示。
不过，总的来说，除非有其他考虑因素，否则应该选择 UTC。
In an embedded system you might well receive the time from a source in some sort of "ticks past epoch" form.
If the time is updated relatively frequently, and displayed relatively infrequently, then you might as well store it in the same way it's supplied to you and only convert it for display when needed.
In general, though, UTC is the way to go unless there are other considerations.
当您确定仅使用当地时间时。
When you are sure that only local time is going to be used.