October 2011 - tz - lists.iana.org

Fixing make check output...
by Kevin Lyda Oct. 13, 2011

Oct. 13, 2011

To get make check to run on Ubuntu, I had to do the following: apt-get install w3-recs sp cp -a /usr/share/doc/w3-recs/html/www.w3.org/TR/1999/REC-html401-19991224 . find REC-html401-19991224 -name '*.gz' -print0 | xargs -0 gunzip I then copied the command make check wanted to run and tweaked it like so: SGML_CATALOG_FILES=HTML4.cat SGML_SEARCH_PATH=REC-html401-19991224/ SP_CHARSET_FIXED=YES SP_ENCODING=UTF-8 nsgmls -s -B -wall -wno-unused-param tz-art.htm tz-link.htm I'm not really sure what tz-art.htm is for, but this is the diff required to make it actually pass... diff --git a/tz-art.htm b/tz-art.htmindex 902371e..f3064ee 100644--- a/tz-art.htm+++ b/tz-art.htm@@ -213,7 +213,7 @@ Supernaw.</td></tr> <tr><td>ID</td><td>272</td></tr> <tr><td>Total Time</td><td>73:05</td></tr> <tr><td>Notes</td><td>Includes the song "Twilight Time Zone."</td></tr>-<tr><td><a href="http://www.allmusic.com/cg/amg.dll?p=amg&sql=10:w9fpxzykldje">AMG Ra+<tr><td><a href="http://www.allmusic.com/cg/amg.dll?p=amg&sql=10:w9fpxzykldje">AM <tr><td>ADO Rating</td><td>2 stars</td></tr> <tr><td> </td></tr>@@ -224,7 +224,7 @@ Supernaw.</td></tr> <tr><td>Label</td><td>Columbia</td></tr> <tr><td>ID</td><td>CK-8905</td></tr> <tr><td>Total Time</td><td>45:36</td></tr>-<tr><td><a href="http://www.allmusic.com/cg/amg.dll?p=amg&sql=10:gifqxqt5ld0e">AMG Ra+<tr><td><a href="http://www.allmusic.com/cg/amg.dll?p=amg&sql=10:gifqxqt5ld0e">AM <tr><td>ADO Rating</td><td>1.5 stars</td></tr> <tr><td>Notes<td>The title song is also available on "Bob Dylan's Greatest Hits" and <tr><td> </td></tr>@@ -235,7 +235,7 @@ Supernaw.</td></tr> <tr><td>Label</td><td>Universal Jazz France</td></tr> <tr><td>ID</td><td>B0012688-02</td></tr> <tr><td>Total Time</td><td>42:31</td></tr>-<tr><td><a href="http://www.allmusic.com/cg/amg.dll?p=amg&sql=10:3bftxzw0ldhe"</a>AMG+<tr><td><a href="http://www.allmusic.com/cg/amg.dll?p=amg&sql=10:3bftxzw0ldhe">AM <tr><td>ADO Rating</td><td>2.5 stars</td></tr> <tr><td>Notes<td>Includes the song "Fire and Wood" with the lyric "The clocks were turned back you remeber/Think it's still November." -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/

1 0

32 municipalities in Mato Grosso, Brazil not to observe DST
by Steffen Thorsen Oct. 13, 2011

Oct. 13, 2011

According to many news sources, 32 municipalities in Mato Grosso will change their clocks for DST the coming weekend, so this will split Mato Grosso into two different zones. One example: http://www.redenergia.com/concessionarias/noticias/5476/Concessionarias-Ger… Biggest city we could find among them was Barra do Garças. Our view of it: http://www.timeanddate.com/news/time/brazil-time-changes-2011.html Best regards, Steffen Thorsen - timeanddate.com

1 0

400-year-repeat edge cases
by Zefram Oct. 12, 2011

Oct. 12, 2011

For tzfile readers that make use of the 400-year cycle where a rule can't be expressed in POSIX-TZ form, I'm concerned that going exactly 400 years beyond the last rule change isn't sufficient. The year at the start of that cycle, the year that would otherwise have been the last one mentioned in the tzfile, might be contaminated by one-shot rules, making it an invalid example of the cyclical rules. Also, the transitions included for the last year of the cycle don't adequately delimit the whole cycle. I propose to avoid these edge problems by adding an extra two years of explicit observations when listing 400 years of the future. One extra year would probably suffice; two certainly does, and allows for conservative tzfile readers to drop poorly-delimited observations at the ends. Think of them as telomeres. Attached patch implements. This affects about six of the tzfiles. (Between five and seven, depending on which of my previous patches you applied.) They mostly get 36 bytes longer. -zefram

1 0

FW: missing extension rules
by Olson, Arthur David (NIH/NCI) [E] Oct. 12, 2011

Oct. 12, 2011

I'm forwarding this message from Zefram; since sending it, Zefram has subscribed to the time zone mailing list. --ado -----Original Message----- From: Zefram [mailto:zefram@fysh.org] Sent: Wednesday, September 28, 2011 6:10 To: tz(a)lecserver.nci.nih.gov Subject: missing extension rules I've found a problem with the tzfiles for Africa/Cairo and America/Argentina/San_Luis. They both show a last known transition in the recent past, and surprisingly lack a POSIX-TZ-format rule for extending the zone into the future. My tzfile parser treats a zone with no extension rule as being undefined for any time following the last explicit transition, so for these two zones it reckons the zone is undefined for the present. In the source files they're each currently configured to observe a set of DST rules, and the ruleset has no transitions configured for the future. So for the present and foreseeable future, the zone is on a constant offset with no DST transitions. The tzfile reflects that by showing no transitions from the present up to 2038 (where zic always fills in a complete set of expected transitions). It should be trivial to also reflect that foreseen behaviour in a POSIX-TZ string that just gives a fixed offset and no DST rule. For example, Africa/Cairo should clearly have "EET-2". I could have a go at a zic patch to fix this, if the regular zic hackers would like to work that way. For America/Argentina/San_Luis there's an extra wrinkle: the last known transition is a transition *to* DST. Its fixed-offset foreseeable behaviour therefore has a fixed is_dst=1, which is moderately silly. It's arguable that in this case it would be incorrect to give a "WARST3" extension rule, because that doesn't accurately express the DST status. Since that DST transition was in 2009, it's also a good bet that they haven't stayed continuously on DST since then, of course. -zefram

3 5

Re: [tz] temporary timezone database home ...
by David Braverman Oct. 11, 2011

Oct. 11, 2011

Um...a statement in a creative work that says "this work is in the public domain" generally *does* put it in the public domain. Anyone who owns property is free to give it away. In the case of the U.S. government, since the government (in theory) is owned by the citizens of the U.S., as a matter of public policy U.S. government works are in the public domain. 17 USC 105 states this explicitly, but does allows the U.S. government to hold copyrights by devise (for example, through a gift or a tax lien). I believe ADO had to clarify that the tzinfo database fell into the first category and not the second; thus, the "public domain" language in the tzinfo files. And IAAL (just not practicing). :) David Braverman http://www.wx-now.com/

4 3

tzdata repo at Google Code is gone
by Øyvind A. Holm Oct. 11, 2011

Oct. 11, 2011

There used to be an svn repo on http://code.google.com/p/tzdata/ containing the tz data in various formats (csv, json, xml, etc), but now it's gone. Does anyone know what happened to it? Anyway, on 2011-10-08 I converted it from Svn to Git, and this repo (with full history, newest version is tzdata2011j) is stored at https://gitorious.org/tz/tzdata . It can be cloned with git clone git://gitorious.org/tz/tzdata.git Regards, Øyvind

1 0

tzdata2011l.tar.gz
by Robert Elz Oct. 10, 2011

Oct. 10, 2011

The file ... ftp://munnari.oz.au/pub/tzdata2011l.tar.gz ...is now available; this reflects changes circulated last week on the time zone mailing list. There are just 2 changes that cause different generated tzdata files from zic, to Asia/Hebron and Pacific/Fiji - the possible change for Bahia, Brazil is included, but commented out. Compared with the diff I sent out last week, this version also includes attributions for the sources for the changes (in much the same format as ado used, but the html tags have not been checked, verified, or used in any way at all, so if there are errors there, please let me know.) Unfortunately, there are no signatures, it turns out that I have not used any form of PGP in so long that getting my keys into a form where they're usable by gpg is somewhat of a challenge - so most probably I'll just generate a new key (as was suggested, and which is obviously the sane approach) for tz distributions - the down side is that at least initially it isn't going to be signed (trusted) by anyone at all... To compensate for this lack of signatures, I'm appending (in this message) a list of digest values, crypto hash function digests generated by a number of different algorithms (all from the NetBSD pkgsrc "digest" program). Those ought to give a fair degree of confidence that the tarball has not been compromised, and by distributing them in this message, essentially no way for anyone to compromise the digest values (which is the one thing that a proper signature would ensure). Lastly, for now, because people seem to be mirroring ftp://munnari.oz.au/pub/oldtz/ I have included the current versions of the data & code files there, as well as their normal home in ftp://munnari.oz.au/pub - previously the oldtz directory contained only the obsolete tarballs. But thanks to Joseph S. Myers, the oldtz directory now includes a few extra archives that I had been missing, including the extremely elusive tzcode2003b which had been replaced before I even new it existed (and no, you don't really want it, it contained a fairly serious bug, which is why it was replaced so quickly...) kre MD5 (tzdata2011l.tar.gz) = bae1b93673e1aef80186c90dfd493f1c RMD160 (tzdata2011l.tar.gz) = b933711b06246c9d452d846a193b53295a966287 SHA1 (tzdata2011l.tar.gz) = c6740ec9645b78750e2109b6d42cd283e16988d7 SHA512 (tzdata2011l.tar.gz) = a1d2dd68ddd3822f94cd817a3e70277e6e9e347c12aa788533d36ad0ad03f0ec39d925301d64c6ab27825212dffd0ec03c3944096ef479318815a8e1f362c841 TIGER (tzdata2011l.tar.gz) = f0578e0cab5f39f13c49b076cc2955da95e9111b98ffe57c WHIRLPOOL (tzdata2011l.tar.gz) = aa6812740e077e064de7348f2deb15e1bfe8cbb93a336dde58e625b76f4832c8c6601bb06437ac04c05b232f142b1119841f5bab50656907b3a1459906c818a1

7 8

Update docs/comments regarding move from elsie to iana
by Kevin Lyda Oct. 10, 2011

Oct. 10, 2011

There are several places in the code that refer to the ftp server and mailing list on elsie. The following patch points people at the currently correct places. Kevin -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/

1 0

Digital signing (was Re: Proposed time zone package changes ...)
by Bennett Todd Oct. 9, 2011

Oct. 9, 2011

For signing the data files, I'm fond of pgp, with gpg being the implementation I trust best. Sadly, standardization efforts seem to end up being used to add sponsorship for certificate signing authorities, we all have seen how well that has worked for SSL. Hope you can go with pgp; the current Certificate Authority fiasco follows as expected from the observation that trust doesn't scale. As for details, I don't know anything wrong with the default algorithms that gpg uses. But ideally you shouldn't be using your own key directly, but rather a new, project-specific key for the project's official contact email address. You can start it off by signing it with your key, and other folks can add signatures after verifying the fingerprint with you offline.

3 2

Another mirror + mirror shell script
by Sebastian Majstorovic Oct. 9, 2011

Oct. 9, 2011

I'd be glad to contribute another mirror, FTP and HTTP, based in Germany: ftp://tzmirror.appealingapps.de http://tzmirror.appealingapps.de If anyone else wants to setup a mirror, here's a one-line shell script which sets one up: /usr/bin/lftp -c 'open -e "mirror --parallel=5 -e -x ^[^t][^z] -i oldtz /pub /path/to/local/directory" munnari.oz.au' If you run it daily, e.g. as a cron, the files on the mirror are always kept up-to-date. Best Regards Sebastian

1 1