[tz] [tz-announce] 2018i release of tz code and data available
michael.h.deckers at googlemail.com
Fri Jan 4 22:56:11 UTC 2019
On 2019-01-04 20:33, Tim Parenti wrote:
> Though I will admit it was not straightforward deriving the intent of that
> substitution from the comments, it is there because the 2018-10-26
> transition was NOT a transition in UT offset. In a rearguard sense, 2018g
> predicted that the new timezone of +01 would be permanent and thus switched
> to +01 with rearguard isdst=0 on 2018-10-26. As it is now expected that
> Morocco will "fall back" to +00 each Ramadan, 2018h and 2018i consider
> rearguard isdst to have instead remained 1 on 2018-10-26 (since there was
> no clock change), and that the flag will become rearguard isdst=0 when the
> clocks fall back each Ramadan.
For release 2018d on 2018-03-22, the text in the NEWS file says:
" * The build procedure constructs three files vanguard.zi, main.zi,
and rearguard.zi, one for each format. The files represent the
same data as closely as the formats allow."
Nothing disallows the "rearguard" format for Africa/Casablanca
to describe exactly the same data as the "vanguard" format,
including the same setting of the dst bit -- it is just a matter
of additional ZONE lines in the "rearguard" format.
Nevertheless, the data described by the different formats
seem to differ in the case of Africa/Casablanca. The question
arises whether the difference is intentional or caused because
one wants to avoid 50 or so more lines in the zic input file.
But in either case, the description in the NEWS file is incorrect.
I do not know whether there is a more official description of
Also in either case, we must state that it is the "vanguard"
format that exactly describes the data we want to describe,
while the other formats may describe data that differ somewhat
for whatever reason.
More information about the tz