是否有充分的理由将时间存储在UTC中？

Question

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

Answer 1

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

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

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

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

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

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

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

事情可能变得相当棘手,但总的来说我发现UTC解决的问题比它引入的更多.

Answer 2

我会说这是依赖于应用程序的.我从事电离层和磁层的空间物理模型研究.我们使用磁性当地时间,将日期和时间存储为修改后的Julian Days.

Answer 3

警报和计划任务有时以本地时间存储,因此它们不受夏令时或时区更改的影响.

你能做到这一切,但为什么呢？它没有给你任何收获. (4认同)
@Pete:想想我的闹钟:闹钟设置为当地时间早上7点.当时钟在冬天回来时,我不想在早上6点醒来.当我出去西部出差时,我不想在半夜醒来,因为早上7点就回家了. (3认同)
因此,对于存储没有任何特定关联日期的时间,使用本地时间是有意义的.好点子. (3认同)
@Dave是的,所以你只需更改TIME_ZONE + = n,所以convertToLocalTime(currentUtc,TIME_ZONE,isDaylightSavingsTime)将返回本地时间(即使它在内部存储为UTC). (2认同)

Answer 4

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

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

它实际上从未在历史上前进(它可能*将来),但平均每1.5年倒退一次.如果我们有一个秒表每秒钟分裂一次,时间就是这样:'58.0 58.5 59.0 59.5 00.0 00.5 00.0 00.5 01.0` http://en.wikipedia.org/wiki/Unix_time (3认同)