时区只是一个偏移量还是“更多信息"? [英] Is timezone just an offset number or "more information"?
问题描述
我住在一个他们一年两次更改时间的国家/地区.即:一年中有一段时间与 UTC 的偏移量为 -3 小时(-180 分钟)，其他时间段与 UTC 的偏移量为 -4 小时(-240 分钟)
I live in a country where they change the time twice a year. That is: there is a period in the year when the offset from UTC is -3 hours (-180 mins) and other period where the offset is -4 hours (-240 mins)
表面上:
|------- (offset = -3) -------|------- (offset is -4) -------|
start of year mid end of year
我的问题是:
时区"只是代表偏移量的数字?那就是:我的国家有两个时区?或者时区包含此信息?
这很重要，因为我将 UTC 时区中的每个日期(偏移量 = 0)保存在我的数据库中.
This is important because I save every date in UTC timezone (offset = 0) in my database.
相反，我是否应该使用本地时区保存日期并保存它们的偏移量(在保存时)?
Should I, instead, be saving the dates with local timezone and saving their offset (at the moment of saving) too?
这是我通过使用 UTC 时区保存日期看到的一个问题示例:
假设我有一个人们发送消息的系统.
我想有一个统计部分，我在其中绘制发送的消息 v/s 小时"(即:在常规日按小时发送的消息")
Here is an example of a problem I see by saving the dates with timezone UTC:
Lets say I have a system where people send messages.
I want to have a statistics section where I plot "messages sent v/s hour" (ie: "Messages sent by hour in a regular day")
假设整个数据库中只有两条消息:
Lets say there are just two messages in the whole database:
- 消息 1，于 3 月 1 日发送，UTC 时间下午 5 点(当地时间下午 2 点)
- 消息 2，于 8 月 1 日，UTC 时间下午 5 点(当地时间下午 1 点)发送
然后，如果我在 8 月 2 日创建绘图，将这些 UTC 日期转换为本地日期会给我:2 条消息在下午 1 点发送"，这是不稳定的信息！
Then, if I create the plot on august 2, converting those UTC dates to local would give me: "2 messages where sent at 1 pm", which is erratic information!
推荐答案
来自 timezone 标签 wiki 在 StackOverflow 上:
From the timezone tag wiki here on StackOverflow:
时区 != 偏移
时区不能仅由 UTC 的偏移量表示.许多由于夏令时"，时区有多个偏移量或夏令时"规则.偏移量更改的日期也是时区的规则，以及任何历史偏移量的变化.许多软件程序、库和网络服务忽略了这一点重要细节，并错误地调用标准或当前偏移量区域".这可能会导致混淆和滥用数据.请尽可能使用正确的术语.
A time zone can not be represented solely by an offset from UTC. Many time zones have more than one offset due to "daylight savings time" or "summer time" rules. The dates that offsets change are also part of the rules for the time zone, as are any historical offset changes. Many software programs, libraries, and web services disregard this important detail, and erroneously call the standard or current offset the "zone". This can lead to confusion, and misuse of the data. Please use the correct terminology whenever possible.
常用的数据库有两种，Microsoft Windows 时区数据库和 IANA/Olson 时区数据库.请参阅维基了解更多详情.
There are two commonly used database, the Microsoft Windows time zone db, and the IANA/Olson time zone db. See the wiki for more detail.
您的具体问题:
时区"只是代表偏移量的数字?那就是:我的国家有两个时区?或时区包含此信息?
the "timezone" is just the number representing the offset? that is: my country has two timezones? or the timezone includes this information?
您有一个时区".它包括两个偏移量".
You have one "time zone". It includes two "offsets".
相反，我是否应该使用本地时区保存日期并保存它们的偏移量(在保存时)?
Should I, instead, be saving the dates with local timezone and saving their offset (at the moment of saving) too?
如果您正在记录事件发生或将要发生的精确时刻，那么您应该存储该特定时间的偏移量.在 .Net 和 SQL Server，这是使用 DateTimeOffset 表示的.其他平台也有类似的数据类型.它只包含偏移量信息 - 不包含偏移量源自的时区.一般以ISO8601格式序列化，如:
If you are recording the precise moment an event occurred or will occur, then you should store the offset of that particular time with it. In .Net and SQL Server, this is represented using a DateTimeOffset. There are similar datatypes in other platforms. It only contains the offset information - not the time zone that the offset originated from. Commonly, it is serialized in ISO8601 format, such as:
2013-05-09T13:29:00-04:00
如果您可能需要在那个时候编辑，那么您不能只存储偏移量.在您系统的某个地方，您还需要有时区标识符.否则，您无法确定编辑后的新偏移量应该是多少.如果您愿意，可以将其与值本身一起存储.某些平台具有完全用于此目的的对象 - 例如 NodaTime 中的 ZonedDateTime.示例:
If you might need to edit that time, then you cannot just store the offset. Somewhere in your system, you also need to have the time zone identifier. Otherwise, you have no way to determine what the new offset should be after the edit is made. If you desire, you can store this with the value itself. Some platforms have objects for exactly this purpose - such as ZonedDateTime in NodaTime. Example:
2013-05-09T13:29:00-04:00 America/New_York
即使在存储 zone id 时，您仍然需要记录偏移量.这是为了解决从日光偏移到标准偏移的回退"过渡期间的歧义.
Even when storing the zone id, you still need to record the offset. This is to resolve ambiguity during a "fall-back" transition from a daylight offset to a standard offset.
或者，您可以使用时区名称存储 UTC 时间:
Alternatively, you could store the time at UTC with the time zone name:
2013-05-09T17:29:00Z America/New_York
这也能正常工作，但您必须先应用时区，然后才能向任何人显示该值.TIMESTAMP WITH TIME ZONE 在 Oracle 和 PostgreSQL 就是这样工作的.
This would work just as well, but you'd have to apply the time zone before displaying the value to anyone. TIMESTAMP WITH TIME ZONE in Oracle and PostgreSQL work this way.
您可以在这篇博文中阅读更多相关信息，而 .Net 则专注于 - 这个想法适用于其他平台，因为好.您给出的示例问题是我所说的保持观察者的视角"——这在同一篇文章中进行了讨论.
You can read more about this in this post, while .Net focused - the idea is applicable to other platforms as well. The example problem you gave is what I call "maintaining the perspective of the observer" - which is discussed in the same article.
这篇关于时区只是一个偏移量还是“更多信息"?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
