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

[Tim Parenti]

On 5 June 2016 at 19:51, Paul Eggert <eggert at cs.ucla.edu> wrote:

> > choosing the local time *after* the transition isn't how most people
> think
> > about transitions in day to day conversation.
>
> True. But it's easy to get used to when looking at zdump -i format. Plus,
> users most likely prefer localtime to UT when thinking about transitions.
>

I realize the goal may be to have a single canonical format, but perhaps
this could be made conditional on a -z option?  Append a "Z" to the
time-of-day when it's UT; don't when it's local.  One of the good things
the existing -v format provides is the ability to confirm that transitions
occur at both the correct local time and Universal time.

To some extent there is a tradeoff between formats that make typos easy to
> find, and formats that are more what users typically expect. Within reason
> I'd rather make typos easy to find


Just to throw in a potential middle-of-the-road option, would it make sense
to space-pad the datetime and offset values instead?  Something like the
following:

TZ="America/Phoenix"
-          -        -072818 LMT
1883-11-18 12       -07     MST
1918-03-31 03       -06     MDT 1
1918-10-27 01       -07     MST
1919-03-30 03       -06     MDT 1
1919-10-26 01       -07     MST
1942-02-09 03       -06     MWT 1
1943-12-31 23:01    -07     MST
1944-04-01 01:01    -06     MWT 1
1944-09-30 23:01    -07     MST
1967-04-30 03       -06     MDT 1
1967-10-29 01       -07     MST

TZ="Pacific/Pago_Pago"
-          -        +123712 LMT
1879-07-04 00       -112248 LMT
1911-01-01 00:22:48 -11     NST
1967-04-01 00       -11     BST
1983-11-30 00       -11     SST

I think that strikes a balance where typos are easy to spot, but the
purpose of each field remains quite reasonably clear.  The handful of extra
bytes seem a worthwhile expense to have a canonical format which can easily
serve both humans and machines alike.

(I would not, however, suggest padding the later fields.)

typos are a real probelm!


;)

--
Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20160606/d10e8fb8/attachment.htm>