Hello, The file http://www.iana.org/time-zones/repository/releases/tzcode2013c.tar.gz indicated in http://www.iana.org/time-zones as being of size 132.4kb is in fact in un-gzipped format and its size is 522240 bytes (i mean: this is the file i get when i wget the path). For the content of it, no problem. Same for tzdata. I suppose that this has been correct at the end of April, since my personal copy has the right format (and small size). Regards, Denis Excoffier.
Denis Excoffier wrote:
Hello,
The file http://www.iana.org/time-zones/repository/releases/tzcode2013c.tar.gz indicated in http://www.iana.org/time-zones as being of size 132.4kb is in fact in un-gzipped format and its size is 522240 bytes (i mean: this is the file i get when i wget the path).
For the content of it, no problem. Same for tzdata.
I suppose that this has been correct at the end of April, since my personal copy has the right format (and small size).
Regards,
Denis Excoffier.
Indeed, the Linux "file" command says this is just a "POSIX tar archive (GNU)" whereas it should say "gzip compressed data". Martin
On 2013-07-05 15:56, Martin Burnicki wrote:
Denis Excoffier wrote:
Hello,
The file http://www.iana.org/time-zones/repository/releases/tzcode2013c.tar.gz indicated in http://www.iana.org/time-zones as being of size 132.4kb is in fact in un-gzipped format and its size is 522240 bytes (i mean: this is the file i get when i wget the path).
For the content of it, no problem. Same for tzdata.
I suppose that this has been correct at the end of April, since my personal copy has the right format (and small size).
Regards,
Denis Excoffier.
Indeed, the Linux "file" command says this is just a "POSIX tar archive (GNU)" whereas it should say "gzip compressed data".
Indeed, `gzip -l tzcode2013c.tar.gz` says "not in gzip format". -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-
Thanks for the heads-up. My guess is that this happened to the new way the tz distribution gets released. For 2013c I gave up on trying to use IANA's VPN software, and simply emailed the signed tarballs to someone who can actually install them. Possibly the recipient email client "helpfully" uncompressed the files. I have asked IANA to fix this, and I am using a different procedure for the 2013d release. This release will correspond to commit 8f10e5c535616f70172584a9ff53232c437f9ca9 dated today in the unofficial github repository at <https://github.com/eggert/tz>. I hope it's published soon, but it may not happen until Monday if the IANA folks are taking the day off; yesterday was a holiday in the U.S. and many people are taking vacation days today.
Date: Fri, 05 Jul 2013 08:46:43 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <51D6EA63.4080609@cs.ucla.edu> | Thanks for the heads-up. My guess is that this happened | to the new way the tz distribution gets released. I doubt it was that simple, I fetched the 2013c files the day they were released (or the day after) and the copies I had (ftp'd from IANA site) were properly gzip'd. What's more, the copies on the IANA (ftp) site don't appear to have been touched since then, and still look to be at least the correct size to be correctly gzip'd. Maybe it is something with the way the http server accesses the files that causes them to get un-gzip'd ? And yes, that looks to be it, I just fetched the 2013c code file from http:// and that one arrived (using the standard NetBSD ftp client that also fetches from http URLs, and wget, and curl) and that version (all 3 times) did arrive ungzip'd. Unless IANA are storing the file in 2 different places (one for FTP and one for HTTP access) then I think it must be something in the way their HTTP server is configured, most likely do they can geep all their other data gzip'd but still deliver readable text to people browsing. Fetching it again today using FTP fetched the gzip'd version. Lesson to learn - avoid HTTP wherever possible, use FTP instead! kre ps: the same behaviour can be observed with the new 2013d files.
On 07/06/2013 04:07 AM, Robert Elz wrote:
Maybe it is something with the way the http server accesses the files that causes them to get un-gzip'd ?
Yes, you're right. It turns out that the IANA folks recently set up Varnish Cache <https://www.varnish-cache.org/> as a HTTP reverse proxy for their web site, and they're still working out the kinks. For now, the compressed files may be delivered in their uncompressed versions. You should be able to use FTP to access the compressed files reliably.
On 07/06/2013 02:15 PM, Paul Eggert wrote:
For now, the compressed files may be delivered in their uncompressed versions. You should be able to use FTP to access the compressed files reliably.
The IANA folks have reconfigured their proxy, so the problem should be fixed now, and HTTP files (like FTP files) should be compressed properly now.
participants (5)
-
Denis Excoffier -
Ian Abbott -
Martin Burnicki -
Paul Eggert -
Robert Elz