以UTC格式存储时间总是一个好主意,还是在本地时间存储更好？

Question

通常,最佳做法是以UTC格式存储时间,如此处和此处所述

假设有一个重新发生的事件让我们说结束时间总是在同一个本地时间,比如说17:00,无论该时区是否开启夏令时.并且当DST在特定时区打开或关闭时,还要求不要手动更改时间.还要求每当任何其他系统通过API(即GetEndTimeByEvent)询问结束时间时,它总是以UTC格式发送结束时间.

方法1: 如果决定以UTC格式存储,则可以将其存储在数据库表中,如下所示.

Event      UTCEndTime
=====================
ABC         07:00:00
MNO         06:00:00
PQR         04:00:00

对于第一个事件ABC,UTC的结束时间是上午07:00,如果转换为从UTC到2012年7月1日当地时间显示,则将在当地时间17:00结束,如果在2012年10月10日转换( DST为时区的开启日期)然后将导致下午6点,这是不正确的结束时间.

我可以想到的一种可能的方法是将DST时间存储在附加列中,并在时区有DST ON时使用该时间.

方法2: 但是,如果它被存储为如下的本地时间,例如对于事件ABC,它将在任何日期始终为17:00,因为没有从UTC到本地时间的转换.

Event      LocalEndTime
=======================
ABC         17:00:00
MNO         16:00:00
PQR         14:00:00

应用程序层将本地时间转换为UTC时间,以通过(API GetEndTimeByEvent)发送到其他系统.

在这种情况下,以UTC格式存储时间仍然是个好主意吗？如果是,那么如何获得恒定的当地时间？

相关问题:是否有充分的理由将时间存储在UTC中？

Answer 1

我认为,为了回答这个问题,我们应该考虑使用UTC存储时间戳的好处.

我个人认为,主要的好处是时间总是(大部分)保证是一致的.换句话说,无论何时更改时区或应用DST,您都不会及时来回.这在文件系统,日志等中特别有用.但是在你的申请中是否有必要？

想想两件事.首先,关于DST时钟转换的时间.您的事件可能会在凌晨2点到凌晨3点之间发生(在时钟转换完成的那天)？那会发生什么？

其次,申请是否会受到实际时区变化的影响？换句话说,你打算从伦敦飞往华沙,并适当改变你的计算机时区吗？在那种情况下会发生什么？

如果您对这两个问题的回答都是" 否",那么您最好使用当地时间.它将使您的应用程序更简单.但是,如果你的回答是至少一次,那么我认为你应该给它更多的思考.

这就是数据库的全部内容.另一件事是应用程序内部使用的时间格式,这应该取决于你将在那个时间实际做什么.

你提到它通过API暴露时间.应用程序是否会在每次请求时查询数据库？如果您在内部将时间存储为UTC,则需要执行此操作或以其他方式确保在DST /时区更改时,将调整/修剪缓存时间.

它会对时间本身做什么吗？像打印一样,事件将在8小时内发生,或者大约在那个时间暂停？如果是,那么UTC可能会更好.当然,您需要考虑所有上述问题.

Answer 2

我喜欢这样想:

计算机不关心时间作为人类可理解的表示.他们不关心时区,日期和时间字符串格式或其中任何一种.只有人类关心如何解释和表达时间.

让数据库做它擅长的事情:将时间存储为数字 - UNIX纪元(自1970-01-01以来经过的秒数)或UTC时间戳(无时区或夏令时信息).只关注自己,必须以人类可理解的方式表达时间.这意味着在您的应用程序逻辑,报告系统,控制台应用程序或人类将查看数据的任何其他位置.

Answer 3

以下内容不适用于真正的多租户全球SaaS产品,因此该意见针对简单的"业务线"应用程序开发人员.

存储为UTC很好,但有一个要求会导致疼痛,如果你这样做:"你能给我写一份报告,告诉我每天发生多少次X？"

如果您将日期存储为UTC,则此要求将导致痛苦; 您需要在应用程序服务器和报告中编写时区调整代码; 您对包含日期条件的数据执行的每个临时查询都需要将其考虑在内.

如果您的申请符合以下条件:

1. 每个实例都基于单个时区.
2. 时区转换通常在办公时间以外,或者您并不真正关心事物的"持续时间",以至于缺少一小时左右的时间.

我建议你将日期时间存储为本地日期时间,同时使用一个库来隔离服务器时区配置问题(例如.net世界中的Noda.Time).

Answer 4

如果您的系统间消息使用ISO 8601,并且您的数据库正在存储原始本地时间+偏移量(如datetimeoffset在MSSQL或ISODateMongo中,因为ISO 8601捕获它)并且您只使用DateTimeOffset.NET或OffsetDateTimeJava或某些等效的你的代码,然后根本不需要转换.你只需存储它.所有比较功能都可以正常工作.

如果在持久性中转换为UTC,则表示您已从用户的视点中丢失了偏移量.十年前用户签署文档时显示现在是一个难题.从UTC开始工作将意味着查找当时在该地区发挥作用的DST规则.恶梦.

我相信我们都习惯转换为UTC持久化的原因是因为我们从未使用过正确的数据结构/数据类型来让我们做正确的事情.