我想知道是否有任何充分的理由将时间信息存储在UTC(GMT)的其他任何内容中？ 我相信这是所有软件工程的坚实规则。 转换为本地时间仅仅是在UI层发生的用于显示目的的转换。 我还看到了为了正确实现算法(处理午夜日期变化等)需要翻译的情况。

一般来说，我发现使用UTC更好。
有时您可能需要当地时间。然后我宁愿选择UTC +时区信息。

一般情况下，重复事件可能非常棘手，您应该非常仔细地分析用例。

想象一下定期会议，每周二上午9:00。
如果DST发生变化，会议仍应在(新的)上午9:00进行。

但是在法国的一些人中没有增加会议。对他们来说，会议是在下午6点。
他们通过不同的规则改变DST。

当你改变夏令时，他们没有，所以有一段时间(直到法国改变夏令时)有人应该"关闭"：要么你的会议将在上午10点，他们的会议将在下午6点，或保持你的会议在上午9点，并移动他们的下午5点。没有其他办法，计算机与它无关。

申请将如何决定谁应该"修复"？
是大多数成员的团体吗？ (美国1个人和法国20个人？)或者这个人的重要性是什么？ (如果美国的那个人是首席执行官怎么办？)

你如何存储这些信息？
我最好的解决方案是使用UTC +一个"主时区"
"主时区"中的用户获胜(保持固定)。

事情可能变得非常棘手，但总的来说我发现UTC解决了比它引入的更多问题。

为了澄清(非常有效的:-)点来自fjsj：by"主时区"我指的是确切的区域，包括有关DST活动与否的信息。

如果您只存储PT(太平洋时间)，那么这还不够。
PST(太平洋标准时间)或PDT(太平洋夏令时)是。

可能更好的是，不要将重复会议视为"固定时间点"，以"纪元"的秒/毫秒表示。编程语言(最终)开始采用JodaTime的概念。

我会说这是依赖于应用程序的。我从事电离层的空间物理模型研究。磁气圈。我们使用磁性当地时间，存储日期和时间。次为修改过的朱利安天。

警报＆amp;计划任务有时以本地时间存储，因此它们不受夏令时或时区更改的影响。

UTC是一种具有TAI准确性和精确度的计时标准，但是以不规则的间隔添加闰秒以使其能够密切跟踪平均太阳时(UT1)。

如果您正在使用的系统无法处理闰秒，那么Bureau International des Poids et Mesures建议使用TAI代替UTC。

请参阅：http：//tycho.usno.navy.mil/leapsec.html

在嵌入式系统中，您可能会从某种"蜱过去时代"形式的源中获得时间。

如果时间相对频繁地更新并且相对不频繁地显示，那么您也可以以与提供给您的方式相同的方式存储它，并且仅在需要时将其转换为显示。

但是，一般而言，除非有其他考虑因素，否则UTC是可行的方法。

自从？我确信在一些孤立的案件中有充分的理由。一般来说，存储UTC比当地时间要好得多，所以我会将UTC视为默认位置，除非有一些特殊的考虑因素。

当您确定只使用当地时间时。