英文:
How to get current IANA Timezone Database version in Golang?
问题
我需要使用 IANA 数据库的当前版本(例如2022g)来存储日期时间记录。我该如何在 Go 中获取它?
我尝试在标准的 "time" 包中搜索,但似乎没有相关功能。我期望有一个函数可以返回 IANA tzdb 版本作为字符串。
根据下面的评论,我需要澄清问题:
主要问题是我想存储一些未来的事件。事件对象有几个字段:
- 本地日期时间
- 时区
- UTC 日期时间
为了使我的数据与 IANA 数据库保持最新(时区、夏令时可能会更改),我需要存储当前 tzdb 版本的版本。这将帮助我在发布新版本的 tzdb 时编写正确的数据迁移。因此,我需要添加一个字段,用于存储用于填充时间的当前 tzdb 版本。
我正在努力弄清楚如何获取 Go 应用程序当前正在使用的 tzdb 版本,以存储该版本。
另外,我也可以接受在存储长期未来事件的同时提供额外准确性的替代解决方案。
更新2:这些事件与具体位置有关。
英文:
I need to store datetime records with IANA database current version used (2022g for example). How could I get it with Go?
I tried to search this on standard "time" package, but it seems that there isn't any functionality for this. I am expecting that there is some function that can return IANA tzdb version as a string.
UPDATE 1 according to comments below I need to clarify the problem:
The main problem is I want to store some FUTURE events. The event object has several fields:
- Local dateTime
- Timezone
- UTC datetime
To keep my data up to date with IANA database (timezone, daylight saving time may change) I need to store current version of tzdb version. That will help me to write correct data migration of my events when new version of tzdb was released. So I need to add one more field with version of current tzdb that had been used to populate the time.
And I am trying to figure out how can I get the current version of my tzdb that Go application is using right now to store that version.
Also I am opened to alternative solutions of storing time records with extra accuracy of long-lived future events.
Update 2: This events are bounded to exact location.
答案1
得分: 2
评论中的讨论线程非常长,但我将尝试回答和解决一些关注点。(我不会回答标题中的问题,因为我认为在Go语言中这并不简单。)
-
的确,未来事件的安排应该以事件发生地的时区为准,通常不是UTC时区。
-
时区标识符将永远不会被删除或重命名(只有极少数例外)。一旦引入,该标识符将作为
Zone
或Link
在TZDB中持续存在。因此,您不需要检查时区是否仍然存在。(Windows的时区ID也是如此。) -
夏令时只是选择正确偏移量的一个方面。标准时间也可能发生变化。然而,所有这些都封装在tzdb中。您不需要关心在创建事件时使用的tzdb版本。
在大多数情况下,解决此问题的一般方法是:
-
存储事件的本地日期、时间和时区ID(相对于事件的时区)。
示例:
2030-12-31T00:00:00[America/New_York]
-
在创建事件时,同时计算一个UTC值(或等效的
DateTimeOffset
值)并将其存储在一个单独的字段中,以便您确切知道何时触发事件:示例:
2030-12-31T05:00:00Z
(或2030-12-31T00:00:00-05:00
) -
定期检查您的UTC等效值是否正确。这可以是每日维护任务、应用程序启动时,或者在事件之前(也许还有事件前一小时),或者以上所有情况。
只有当设备上的时区数据发生变化以获得新的偏移量时,偏移量才会与预期不同。例如,假设美国的立法者在此事件发生之前成功地使夏令时永久化。那么,同一事件的等效UTC时间现在将是
2030-12-31T04:00:00Z
(或2030-12-31T00:00:00-04:00
)。在这种情况下,如果事件的UTC时间发生了变化,更新事件的UTC时间,但通常不应修改事件的原始本地时间。人们倾向于按照本地时间安排事务,而不是按照其UTC等效时间。
知道TZDB版本的唯一好处是,您可以更少地执行最后一步操作,只有在知道数据已更改时才执行。我认为这是一种优化,通常不是必需的。
-
如果没有对时区定义进行法律变更,仅仅按计划开始/停止夏令时不是一个值得担心的原因。这已经通过使用TZDB来考虑到了。
- 如果事件是重复的(比如每天上午10点的会议),每个事件可能具有不同的偏移量,但本地时间将保持一致,不需要更新TZDB来计算它。
英文:
The discussion thread in the comment is pretty long, but I'll attempt to answer and address some of the concerns. (I won't address the question in the title, as I believe that is not straightforward in Go.)
-
Indeed, future scheduling of events should be in terms of the time zone where the event takes place - which is usually not UTC.
-
Time zone identifiers will never be removed or renamed (with rare exception anyway). Once introduced, the identifier will either maintained as a
Zone
or as aLink
in the TZDB indefinitely. Thus, you don't need to check that the time zone still exists. (Windows time zone IDs are also like this.) -
DST is only one aspect of picking the correct offset. The standard time may have changed as well. However, all of that is encapsulated in the tzdb itself. You shouldn't need to concern yourself about which version of the tzdb was in effect when you created the event.
The general approach to this issue in most cases is:
-
Store the scheduled local date, time, and time zone ID of the event (local with regard to the time zone of the event).
Example:
2030-12-31T00:00:00[America/New_York]
-
At the time you create the event, also calculate a UTC value (or equivalent
DateTimeOffset
value) and store that in a separate field - so you know exactly when to fire the event:Example:
2030-12-31T05:00:00Z
(or2030-12-31T00:00:00-05:00
) -
Periodically check that your UTC equivalent is correct. This can be in a daily maintenance task, or on application startup, or just before the event (perhaps also an hour before the event), or all of these.
The offset will only be different than projected if the time zone data changed on the device to give it a new offset. For example, let's hypothetically say the lawmakers in the USA succeed at making DST permanent sometime before this event takes place. Then the equivalent UTC time for the same event would now be
2030-12-31T04:00:00Z
(or2030-12-31T00:00:00-04:00
).In such cases, update the UTC time of the event if it has changed, but the original local time of the event usually should not be modified. Human beings tend to schedule things in terms of local time, not in terms of their UTC equivalents.
The only advantage knowing the TZDB version would give you, is you could do that last step less often - only when knowing the data has changed. I see that as an optimization though - it's not usually required.
-
Without such legal changes to time zone definitions, the mere start/stop of DST as scheduled is not a reason to worry about this. That is already accounted for by using the TZDB in the first place.
- If the event is recurring (say a 10:00 AM daily meeting), each occurrence might have a different offset, but the local time will be consistent and the TZDB doesn't need to be updated to calculate it.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论