[tz] zdump new option -i for easier-to-review output

[Jon Skeet]

For anyone else still following this, I have an experimental converter
<https://github.com/nodatime/tzvalidate/tree/master/csharp/src/NodaTime.TzValidate.ConvertTzs>
(in
C# at the moment) from the "tzs" format (for want of a better name) to
the tzvalidate
format <https://github.com/nodatime/tzvalidate/blob/master/format.md> we've
been using. (I'm pleased to say that the results then concur, which is
always reassuring.) I'll amend that code to handle Paul's latest patch when
the next version of the time zone data comes out.

Jon


On 19 December 2016 at 18:03, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 08/21/2016 03:42 AM, Paul Eggert wrote:
>
>> Jon Skeet wrote:
>>
>>> I'd stlil argue for
>>> colons in offsets (RFC5322 uses a horrible format in general; I see no
>>> reason to copy mistakes of the past)
>>>
>>
>> Tim argued for that as well, so let's do that.
>>
>
> After having used it for a while, the colons output by zic are getting in
> the way of my manual audits of zdump -i output. The tz database omits ":"
> in numeric time zone abbreviations, not only because of longstanding
> tradition exemplified by Internet RFC 5322, but also because the POSIX TZ
> format does not allow ":" there. "zic -i Asia/Colombo" therefore outputs
> lines like this:
>
> 2006-04-15    00    +05:30    "+0530"
>
> where the quoted string indicates that something is amiss because the
> abbreviation is not alphabetic and does not match the computed
> abbreviation. To fix this, the attached proposed patch causes zic to
> compute the abbreviation "+0530" instead, causing its output line to look
> like this:
>
> 2006-04-15    00    +0530
>
> which makes it clearer that the situation is expected and does not need
> further attention.
>
> It may be that we'll need at some point to have a way to add colons to the
> tz database's time zone abbreviations, for people who prefer that style and
> are not worried about POSIX compatibility. I suppose this can be a topic
> for a future patch. It would need to be done carefully as it would likely
> require a change to the version number in compiled tzdata files, as it
> would change the format of their embedded TZ strings.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20161219/dc3499cc/attachment.html>