[tz] timezone DB distribution

[Guy Harris]

On Aug 17, 2020, at 2:07 PM, Juergen Naeckel via tz <tz at iana.org> wrote:

> I tried to use the data provided in the timezone files.  I ran some consistency checks.  I think I found some inconsistencies.
> 
> Zone America/Barbados – has rule BARB, but none of the BARB rules is currently valid.

"Barb", not "BARB".

I think

# Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER/S
Rule    Barb    1977    only    -       Jun     12      2:00    1:00    D
Rule    Barb    1977    1978    -       Oct     Sun>=1  2:00    0       S
Rule    Barb    1978    1980    -       Apr     Sun>=15 2:00    1:00    D
Rule    Barb    1979    only    -       Sep     30      2:00    0       S
Rule    Barb    1980    only    -       Sep     25      2:00    0       S

means "the last transition between Daylight Saving Time and standard time was on 1980-09-25, and it switched to standard time; they've been on standard time ever since".  Perhaps the documentation (currently, the zic man page) should make that a bit clearer.

An alternative would, I think, be to have the Zone and continuation lines for Barbados be something such as

Zone America/Barbados   -3:58:29 -      LMT     1924 # Bridgetown
                        -3:58:29 -      BMT     1932 # Bridgetown Mean Time
                        -4:00   Barb    A%sT    1980
                        -4:00   Barb    AST

or

Zone America/Barbados   -3:58:29 -      LMT     1924 # Bridgetown
                        -3:58:29 -      BMT     1932 # Bridgetown Mean Time
                        -4:00   -       AST     1977
                        -4:00   Barb    A%sT    1980
                        -4:00   -       AST

> Zone America/Costa_Rica – has rule CR, but none of the CR rules is currently valid.Zone America/El_Salvador – has rule BARB, but none of the rules is currently valid
> 
> Zone America/Guatemala – has rule Salv, but none of the rules is currently valid
> 
> Zone America/Tegucigalpa – has rule Hond, but none of the rules is currently valid

I think the same applies there.

> The zone Africa/Johannesburg uses an undefined rule SA

The current version of the africa file in the Git repository has

# South Africa
# Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER/S
Rule    SA      1942    1943    -       Sep     Sun>=15 2:00    1:00    -
Rule    SA      1943    1944    -       Mar     Sun>=15 2:00    0       -
# Zone  NAME            STDOFF  RULES   FORMAT  [UNTIL]
Zone Africa/Johannesburg 1:52:00 -      LMT     1892 Feb 8
                        1:30    -       SAST    1903 Mar
                        2:00    SA      SAST

which defines the SA rules directly above the Africa/Johannesburg zone.

> The zone Africa/El_Aaiun uses an undefined rule Morocco
> 
> The zone Africa/Casablanca uses an undefined rule Morocco

In the current version, the Rule lines for Morocco are above the Zone entry for Africa/Casablanca.

> The zone Indian/Mauritius uses an undefined rule +04/+05

In the current file, it has

# Rule  NAME    FROM    TO      TYPE    IN      ON      AT      SAVE    LETTER/S
Rule Mauritius  1982    only    -       Oct     10      0:00    1:00    -
Rule Mauritius  1983    only    -       Mar     21      0:00    0       -
Rule Mauritius  2008    only    -       Oct     lastSun 2:00    1:00    -
Rule Mauritius  2009    only    -       Mar     lastSun 2:00    0       -
# Zone  NAME            STDOFF  RULES   FORMAT  [UNTIL]
Zone Indian/Mauritius   3:50:00 -       LMT     1907 # Port Louis
                        4:00 Mauritius  +04/+05

The rule for Indian/Mauritius is Mauritus, the format used for the time zone string is "+04/+05", so dates look something like

	Wed Aug 19 07:22:27 +04 2020

(it would be +05 if DST were in effect).

> The zone Pacific/Tongatapu uses an undefined rule Tonga

No, they're there, at least in the current Git version; the same applies to the other examples.  Read the file in a text editor, not in Excel.

> I spot checked several of those – and there is no more daylight saving for those regions.  Thus, the zone definition should contain a dash.

They could have continuation lines with -, including the final continuation line, as per the above; it's not a requirement, however.

> I noticed some more inconsistencies specific to the “asia” file.  The data separator is flexible.  Everywhere, the tab is used as a separator.  Here, the tab and the space are used interchangeably.  Also in all the other files, the “Zone” is followed by a space and then the name.  In this asia file, I noticed frequent use of tabs in between.  Do you use space and tab alike?

As noted, the file format does not require particular forms of white space.