[tz] [PATCH 5/5] Standardize zone table comment format

J William Piggott elseifthen at gmx.com
Tue Feb 23 13:22:48 UTC 2016

On 02/22/2016 01:05 AM, Paul Eggert wrote:
> This one will require a bit more thinking.
> The original design goal was to run 'tzselect' on a traditional 24x80
> alphanumeric screen. It was important to keep the commentary short, so
> as to not overrun the columns. Switching to a more-consistent layout
> convention would probably make us go over the limit.

It doesn't, see below.

> In this way of selection, it's more important for the alternatives to be
> easy to understand, than for them to be consistent. Of course
> consistency and ease of understanding often go hand in hand, but not
> always.
> Perhaps you have a different selector in mind, and in that case we might
> need to consider having a portable scheme that will work with both kinds
> of selectors (albeit perhaps not as nicely as a scheme tailored for your
> particular selector). Am I right in my guess?

Hello Paul,

You are correct that I have written a tzselect style application using a
'dialog' UI. However, my submission is not tailored to it. I need both
versions to work well. Besides, I would not knowingly make a submission
to benefit my needs at the detriment of a project. The reasons I stated,
and the examples given, are the true motivation of the patch.  Using the
same format to represent different data types makes it impossible to
reliably interpret the information.

Throughout development I have been extensively testing and comparing
both tzselect applications, which is how the bugs in the reference
implementation were discovered.

String length has been taken into consideration in defining the zone
table comment standard format.  The only part of the definition that has
significant impact on length is:

 * Use full words in favor of abbreviations.

It is intentionally worded to not exclude the use of abbreviations.

As it turns out, no abbreviations were need to prevent (any further)
breaking of 80 columns (the current comments are already broken).

So lets evaluate the impact of the zone table comments on the shell
'select' function. First lets define the scope of the discussion as
limited to the third round of tzselect input, choosing a local region,
using the zone1970.tab file.

There are only two countries with more than 24 local regions which could
use a two column select menu: US and CA with 29 and 28 regions respectively.

To insure two column capability the strings must be limited to 35
characters. For single column menus the string max is 76 characters.

The current zone table comments for US and CA far exceed the ability to
use a two column select menu. Using the standard format decreases the
longest string for US and stays the same for CA:

 US: current longest comment 71 characters, patched 61
 CA: current longest comment 75 characters, patched 75

The longest comment in the zone1970.tab file is for MX Durango:
  current 84
  patched 79

The patch reduces MX Durango's length, but still exceeds the 76
character limit. This is the contents fault, not the format.

Addressing the length issues is on my todo list, but that needs to be a
separate submission.

Summery: most of the comments require a limit of 76 character, the two
exceptions, US and CA, far exceed the 35 character limit to facilitate
two columns. In other words, unless there are drastic changes in the
content of the US and CA comments, then all comment strings have a 76
character max. Both with and without this patch there is only one
comment in violation, MX Durango.

149 (74%)  reduced or unchanged
 41 (20%)  less than 5 character increase
 11 (05%)  less than 18 character increase

Attached is a head to head comparison of the current zone1979.tab
comments and the patched versions.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: cmp-comment-fmt.txt
URL: <http://mm.icann.org/pipermail/tz/attachments/20160223/126ecc17/cmp-comment-fmt.txt>

More information about the tz mailing list