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 these formats. 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. Michael Deckers.