May 2014 - tz - lists.iana.org

xkcd on time
by David Braverman June 15, 2014

June 15, 2014

Not strictly on-topic, but close enough, and others on this list may find this amusing: http://xkcd.com/now David Braverman Chicago

18 27

changes to the TZ database over versions
by Joris Van den Bogaert June 2, 2014

June 2, 2014

Hello, I'm investigating how to deal with timezones for an application that will get to processes billions of timestamped events, generated in just about any part of the world. Timestamps are in local time (without timezone, only post- and other codes) and we need them in UTC time. Money is involved, so it is of critical importance that intervals between events are calculated correctly. There's two steps involved in this: - given some geo data and some lookup tables from a database like geopostcodes.com, determine the timezone id - convert to UTC using the latest Time Zone Database Development wise it's fairly simple to automate. We're using joda time and this library allows to plugin a custom Timezone provider which can then use the latest TZ database. However, I see some issues: 1) I noticed that certain timezone ids are deleted in newer versions: tzdata2014a contains America/Shiprock, newer versions don't. This may lead to issues whenever recalculations are needed in the future. What is the likelyhood that ids are deleted? 2) Do rules from the past ever change? In other words, can we assume that a recalculation of a past local date to a UTC date will always yield the same result with newer versions of the TZ database? If so, is this a common thing and would one then recommend saving the TZ database version with which the conversion was performed along with the UTC date? Hope one of you can shed some light! Cheers, Joris

5 9

Asia/Vladivostok
by Hank W. May 31, 2014

May 31, 2014

In the europe file, regarding Zone Asia/Vladivostok, in the line shown below, is "VLA%sST" a typo? Should it not be "VLA%sT"? 9:00 Russia VLA%sST 1992 Jan 19 2:00s Hank W.

2 1

Europe/Moscow
by Hank W. May 31, 2014

May 31, 2014

For the period from 1919 Jul 1 2:00 to 1922 Oct in the Europe/Moscow zone the Europe file says to apply the Russia rules with the format MSK/MSD: 2:30:48 Russia %s 1919 Jul 1 2:00 3:00 Russia MSK/MSD 1922 Oct However, the Russia rules show three different offsets during 1921, 0, +1 and +2: Rule Russia 1919 only - Aug 16 0:00 0 - Rule Russia 1921 only - Feb 14 23:00 1:00 S Rule Russia 1921 only - Mar 20 23:00 2:00 M # Midsummer Rule Russia 1921 only - Sep 1 0:00 1:00 S Rule Russia 1921 only - Oct 1 0:00 0 -

2 3

Cook Islands
by Hank W. May 30, 2014

May 30, 2014

In the australasia file, The Cook Islands are under the heading of Australia. However, Wikipedia identifies The Cook Islands as a country in free association with New Zealand.

2 1

Chatham Islands
by Hank W. May 30, 2014

May 30, 2014

In the New Zealand part of the australasia file is the note "Since 1957 Chatham has been 45 minutes ahead of NZ, but there's no convenient notation for this so we must duplicate the Rule lines." However, the Chatham Islands and the mainland always change their clocks at the same time, and there is a convenient notation for the time: 14:00u.

2 1

Morocco
by Hank W. May 30, 2014

May 30, 2014

I noticed that the africa file shows that Morocco will be switching to Summer Time early on 30th October 2038 and switching back to standard time 24 hours later. I thought that might be an oversight because it's hard to believe.

2 1

[tz-announce] 2014d release of tz code and data available
by Paul Eggert May 28, 2014

May 28, 2014

The 2014d release of the tz code and data is available. No substantive changes were made to the tz data, just to the code and documentation. This release reflects the following changes, which were either circulated on the tz mailing list or are relatively minor technical or administrative changes: Changes affecting code zic no longer generates files containing time stamps well before the Big Bang. This works around GNOME bug 730332 <https://bugzilla.gnome.org/show_bug.cgi?id=730332>. (Thanks to Leonardo Chiquitto for reporting the bug, and to Arthur David Olson and James Cloos for suggesting improvements to the fix.) Changes affecting documentation tz-link.htm now mentions GNOME. Here are links to the release files: ftp://ftp.iana.org/tz/releases/tzcode2014d.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2014d.tar.gz The files are also available via HTTP as follows: http://www.iana.org/time-zones/repository/releases/tzcode2014d.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2014d.tar.gz Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. As usual, links to the latest release files are here: http://www.iana.org/time-zones/repository/tzcode-latest.tar.gz http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz ftp://ftp.iana.org/tz/tzcode-latest.tar.gz ftp://ftp.iana.org/tz/tzdata-latest.tar.gz This release corresponds to commit a91cc14d7fe3ef7710e02dcc0da649fdb3bdc3cc dated Tue May 27 21:34:40 2014 -0700 and tagged '2014d' in the unofficial github repository at <https://github.com/eggert/tz>. Here are the GPG checksums for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJThWf4AAoJEO2X6Q5iqn401mgP/0mwb5ijJnOqWb82X4SQmKGW 8GR3HHgRv8N0jDfd1+uOSQXnZ3NptayJWjGx6eBFssCTnmkaGnDbJ/H5Cs3DKyo3 0vekKxJ59MeK3Aw4leJ7bx+fUvzv3yCa+0zT3kkFyYax3mWmX76bsBorU1OUTT0O frTrXEveyA8bibeDNsMISyO8D//S67mv6/nu/wbEiyxufKuizBahfpyncC+o0R8i hkIOcFUHS4X925ezwn7MO5GYXwJ8n7Ho3SWnyDSqBwRt3CRBUDXwz6CkAjZUgHcH zuwSmKDjBBuHXRZ2zGkadr3UBY5rD2HabR1EzwP0hiDNQbFdiuKWmxolHfVy5vVn 5gakHRqsqOYVAkHco+FLpwZO230KO9VWyDpQyvKMZlHX2RYITXL6FYurh7dZxlgp NHcN9ZBOEA0A3lgNTrH5OCocWVGXqqY3dc14gmQLqe9slZdIu+5flfajS17HlYec 1sXRiomso/aVVUaPHFhtyMtuOFLCepFLBg63dQHxYoCfHLGSydbWUB/JcAnMfS8P YOqzovi+FPq6pdyG/q/PUI7FyEz/XZVyc6VazZyF7sqyE9o6JFPYGu7TtyXDNERd Ks3chCsb4tiQ4Wxlh7X8A9HWtu9nCbrJXlOSbWOSbntcbT/tcXClyGi7jkSLt0Aw Gr/4LYioKmoj5TyJ7kDV =TncV -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJThWf4AAoJEO2X6Q5iqn40NTgP/21cbRGXRSc+18Yj7sEQ+fs3 g0zJnUEeZX2Wh7dPnpAH8g8/+htF+LhAS6R1Da8GQZqhHg8NnWplvy5YQuW4oMI8 62Cq+fq8FtGzd12BZSbQc71DItPptuDF6Gnx6S97V4LFxwbiehgha0YTQ+5IUWn2 GOUZRCvr/uhlP96Y0dlgcCRUZxBbxSyLUQBDPlikRegALlgchSm3EU4E2tHMHPDi EhKINic81UKiBPLLWGoaCQXSnOHCyeqKQJJqH9PXqKykCJMeCDHAbUBdo7vRhYx/ 7aHP1javXYMDH1U9C3SqQtIAo9zCObLPtLASYL+KYgJquPcGX+YobuFnb97x6sAH lF0FlCjRJBwdq6oZ/H3NCCFHIMmrVVj+KM0DlCSqUsp9Pld9BUd3F5EK2RGvF3b4 4G58S6Ob+4HDorHqLFfWdsIhRFF3Jr2AWH1VCVPkVxbYBtH7udeDZmL8Z7NgxGSA h9Gwy3wngfLpaD3NCtSDUW0jNc5Yvg9BNw2nwa/VA2A2/ckMjoRe9fGr1WPaY87J 6Rzp57X8l5OxLu2RI54tKioHVIrTfbejXQpISFtE79b4kCmggLTPU1dUWo7yDJvS 7vX6Bd0BLYyrIQKjoTQ30YQpg477lyaBMVS0P8AIl4FSTS7kVGpPaK5lUDANssRB l9vEDH3V46FN0whnKHNe =wEHb -----END PGP SIGNATURE----- _______________________________________________ tz-announce mailing list tz-announce(a)iana.org https://mm.icann.org/mailman/listinfo/tz-announce

1 0

tzcode-2014c breaks applications that use the binary tz files
by Leonardo Chiquitto May 26, 2014

May 26, 2014

Hi, After updating to 2014c, we've received a couple of reports of applications that started to misbehave (show wrong times). One example is the clock applet from Gnome3 (the one in the panel) which, on my machine, shows the time with a -7 minutes offset. Reverting these recent changes from zic(1) resolves the problem: 7fb077a9f zic: improve handling of low-valued time stamps 2586e998c zic: revert Macquarie-specific changes Leonardo

9 15

Politics of TZ changes
by Matt Johnson May 20, 2014

May 20, 2014

The recent changes in Egypt have me thinking. How is it that there isn't some sort of international treaty, law, or agreement about how much notice a government needs to give when making time zone changes? I know almost nothing about international law, but aren't there organizations that coordinate things like trade and commerce that would have something to say about this? It's seems strange to me that we can all agree to let the ITU coordinate UTC while time zones don't seem to be coordinated by any official legal body. Of course, it makes sense that each government should retain its sovereign right to set its time zones as it pleases - but surely something could be done about the process as to which it enacts those changes? I think we can all agree that having a spokesperson give vague details in a media article a week beforehand is not the right way to do things. It's also concerning that people tend to set deadlines based on the date of the change. Not only should time be allowed for the change to be incorporated into the data and distributed to systems, but also people should think about all of the ways that future activities are scheduled based on current knowledge of the tz rules. For example, say you have a weekly scheduled conference call between Egypt and somewhere else in the world. At the moment the Egyptian government announced the change, some of your meeting times became inaccurate. With the change sent out today (2 days before the change), it's not very likely you would receive this update in time to adjust your meeting time. But even if you did get the update, it's quite likely that you would have to reschedule due to conflict with another appointment. For some, this might be an inconvenience. But for others, it could make or break a deal. Cumulatively this could have an economic impact, so one would think it would be in a countries own best interest to give sufficient notice. Perhaps if there were a set of rules, they might be unenforceable and some cases would still slip through the cracks. But at least if there were guidelines defined by some sort of official international governance - we might have a fighting chance. Please share your thoughts and opinions on this topic. What would these rules/guidelines look like? Who might we lobby to enact such a thing?

15 18