Antonio Diaz Diaz wrote:
It is indeed an easy thing to add, and it has been requested a couple times[1][2], but Igor Pavlov does not consider it a priority.
If it's that easy to add, perhaps you could do that and send in a patch. Even if it's low priority for the maintainer, if the code and documentation are already written it shouldn't be hard for the maintainer to install a patch. This would help encourage the use of lz format.
I would consider bzip2 the second best choice; it decompresses safely on all platforms at the only cost of an unimportant increase in tarball size. IMO gzip is also fine. Xz is the only format that I consider should be avoided.
bzip2 is about 11% bigger than lzip for our purposes, though. The .bz2 combined file is bigger than the gzipped data file, which is a downer: $ ls -l tz*.tar.*z* -rw-r--r-- 1 eggert eggert 202609 Aug 30 14:00 tzcode2016X.tar.gz -rw-r--r-- 1 eggert eggert 394169 Aug 30 14:00 tzdata2016X.tar.gz -rw-r--r-- 1 eggert eggert 426667 Aug 30 14:10 tzdb-2016X.tar.bz2 -rw-r--r-- 1 eggert eggert 382991 Aug 30 14:00 tzdb-2016X.tar.lz As there are multiple free MS-Windows-based utilities that can decompress lzip format, I guess we can ask our MS-Windows users to use one. They can continue to use the existing gzip-based tarballs as well, since they will be distributed for a while. So, I'm inclined to go back to .lz format despite the lack of current 7-Zip support, as in the attached proposed tz patch.