[tz] timezone DB distribution

Guy Harris guy at alum.mit.edu
Wed Aug 19 03:30:05 UTC 2020


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.



More information about the tz mailing list