- tz - lists.iana.org

broken compression in archive
by Zefram Jan. 18, 2018

Jan. 18, 2018

I'm doing some work on how to access historical tzdb versions, and I noticed that tz{code,data}94d.tar.Z are, despite their names, uncompressed tar files. To be precise, I refer to the files with these SHA-512 hashes: 9872b757ee3a8bf0ed3de1f0875f878b977b34bd2b60440b23a8c7308a7514d12a5d5d283387973e61b75e1a8eebd27009aab78eee4e12f1f1a5593f71941328 tzcode94d.tar.Z e1524951a5c261cc8eef1f3adadf5ebf8143293745fda9411a0090d6bb6e19f899dd7a6e55fe2f8f490a167a3da392020e49b369984bc1f5cbed87d664eb58de tzdata94d.tar.Z They're unique, in the present archive <ftp://ftp.iana.org/tz/releases/>, in having a mismatch between format and filename suffix. I think these files should be replaced, in the archive, with actual compressed (with compress(1)) versions of these tars, under the same name, so that the names are no longer misleading and they are in the same format as the surrounding files. The other way to make the names no longer misleading is to rename these files, dropping the ".Z" suffix, but this approach has the problem that these files would (still) have a different format from all the other tarballs. Note that this mismatch is not a mistake made in the original release of 94d, and the replacement that I'm proposing would not erase a record of the original release files. The original 94d release was of *gzipped* tar files, which are not in the present archive. Actual releases switched from .Z to .gz at 93g, but the archive files switch at tzdata95c and tzcode95d. Obviously someone recompressed the intervening tarballs somewhere along the chain of custody that led to the present archive, and it appears that the failure to (re)compress 94d happened in that process. -zefram

4 6

Fwd: Issue with tzdata2018a.tar.gz Europe/Dublin Rule
by Vicky Jan. 18, 2018

Jan. 18, 2018

Hi, while parsing the data i found the issue in rule Europe/Dublin Negative DST.. Previous version or not in any other file there is no negative dst. DST either start and end . # The following is like GB-Eire and EU, except with standard time in # summer and negative daylight saving time in winter. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule Eire 1971 only - Oct 31 2:00u -1:00 GMT Rule Eire 1972 1980 - Mar Sun>=16 2:00u 0 IST Rule Eire 1972 1980 - Oct Sun>=23 2:00u -1:00 GMT Rule Eire 1981 max - Mar lastSun 1:00u 0 IST Rule Eire 1981 1989 - Oct Sun>=23 1:00u -1:00 GMT Rule Eire 1990 1995 - Oct Sun>=22 1:00u -1:00 GMT Rule Eire 1996 max - Oct lastSun 1:00u -1:00 GMT Please explain why -ve dst offset compared with other files. Regards, Vaibhav

1 0

Re: [tz] Build error on tzdb-2018a
by Paul Eggert Jan. 17, 2018

Jan. 17, 2018

Matias Fonzo wrote: > I can't update tzdb-2018a, I am getting this error: > > make: *** No rule to make target 'pacificnew', needed by 'version'. Thanks for reporting this packaging problem, which was not detected by the checks that I do before making a distribution. I have installed the attached patch to the development version; please give it a try. Because this problem was caught before I announced 2018a, I will hold off on making an announcement. Instead, I plan to wait a day or so for review of this patch, and then release 2018b with this patch.

2 3

tzdata2018a released
by Seán Coffey Jan. 17, 2018

Jan. 17, 2018

It looks like 2018a has been released with a typo on the release date stamp : (Released 2010-01-12) [1] No announcement was sent to the announcement mailing list. Can the administration of such releases be made more transparent please ? The same type of admin issue happened during 2017. regards, Sean. [1] https://www.iana.org/time-zones

2 1

Missing pacificnew data file
by Kerry Shetline Jan. 17, 2018

Jan. 17, 2018

Hi, I just downloaded the 2018a distribution of the tz database, with code. I tried to do a “make” and the make failed due to the missing pacificnew file. Copying that file from 2017c fixed the problem. The Java tool tzupdater also fails because of this missing file. I realize it might be that you are deliberately getting rid of this file, but your own make process is broken with the file missing, and I imagine other tools for updating time zone data besides tzupdater will also fail due to this file being gone. If you accidentally left pacificnew out, you might need to re-release the distribution. If getting rid of it was intentional, you’ll have to update your make process, or perhaps include a blank or commented-out copy of pacificnew. I also didn’t notice any changes in Brazil or Ireland as I expected to see from the release notes, which possibly is another problem. -Kerry

2 1

Brazil moves DST start to November
by Steffen Thorsen Jan. 17, 2018

Jan. 17, 2018

According to many media sources, next year's DST start in Brazil will move to the first Sunday of November, and it will stay like that for the years after. Some examples in Portugese: https://noticias.r7.com/economia/por-eleicao-temer-reduz-periodo-de-horario… https://exame.abril.com.br/brasil/por-eleicao-temer-reduz-periodo-de-horari… We have made a brief English summary: https://www.timeanddate.com/news/time/brazil-delays-dst-2018.html Best regards, Steffen Thorsen - timeanddate.com

4 7

Canada/East-Saskatchewan
by Derick Rethans Jan. 16, 2018

Jan. 16, 2018

Hi, I saw that the PHP build with the new timezone database (2017.3) failed due to Canada/East-Saskatchewan suddenly being gone. What's up with that? https://travis-ci.org/php/php-src/jobs/291636544#L1280 cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php twitter: @derickr and @xdebug

6 9

leap-seconds.list file is out of date
by R. Bonomi Jan. 15, 2018

Jan. 15, 2018

The iana.org file only contains info through Bulletin C54, but Bulletin C55 is out. Reference: the leap-seconds.list file at usno.mil

3 2

Mongolian time zone.
by Phake Nick Jan. 13, 2018

Jan. 13, 2018

Currently, tz database say Mongolia use UTC+7/8/9 as timezone. However, after quick google search, I found a question about time of Mongolia in a Mongolia question and answer time at [1]. The page itself is facing technical problem to me so I accessed it via Google cache which I subsequently thrown the cache into Google translate and archived the result at [2]. According to the page from 2016, three different users of the site answered the question with same answer, and all of them are saying Mongolia have three different timezone: 6, 7, 8. This is different from the information recorded in tz database. So, is the information in tz database incorrect? And then, another question on the site [3] (archived in [4]) asked about when did Mongolia start officially using the world time and someone answered since 1997. What does that mean? (On the other hand, another answer to a similar question say 1961... [5][6] or is that an error in machine translation?) [1]: http://acyy.mn/3379/монгол-улс-хэд-хэддүгээр-цагын-бүсэд-оршдог-вэ [2]: http://archive.is/y3jpH [3]: http://acyy.mn/8620/монгол-хэдэн-оноос-дэлхийн-бүсийн-цагийг-хэрэглэж-эхлэс… [4]: http://archive.is/PQBVk [5]: http://acyy.mn/7379/му-хэдэн-оноос-дэлхийн-цагийг-баримтлах-болсон-бэ [6]: http://archive.is/e39nW

2 1

Sao Tome Principe change of time zone
by Steffen Thorsen Jan. 9, 2018

Jan. 9, 2018

Multiple sources tell that Sao Tome changed from UTC to UTC+1 as they entered the year 2018: https://www.dn.pt/lusa/interior/relogios-avancam-uma-hora-em-sao-tome-e-pri… http://pt.rfi.fr/sao-tome-e-principe/20180101-sao-tome-e-principe-muda-de-h… http://www.stp-press.st/2017/12/23/sao-tome-e-principe-vai-mudar-hora-a-par… So it seems the Africa/Sao_Tome zone needs to activated again! Our English summary: https://www.timeanddate.com/news/time/sao-tome-principe-time-zone-change.ht… Best regards, Steffen Thorsen - timeanddate.com

3 3