On Aug 17, 2020, at 2:07 PM, Juergen Naeckel via tz <tz@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.