[tz] zdump broken with latest Cairo changes?

[Tim Parenti]

Yes, 2016 has been a bit of an exception, since DST is only being observed
in the ~3.5 months after Ramadan (although we lack an exact end date), and
not in the ~1.5 months before.

Although there's no official word, it seems somewhat logical that this
trend might actually continue in the short-term (e.g., 2017–2019), but what
will happen after that (e.g., beginning in 2039) is anyone's guess. Of two
potential DST periods on either side of a given year's Ramadan, which one
might be observed? The longer of the two? Both if they're of sufficiently
equal length? Given Ramadan is formally observed and not calculated, how
would this be determined? I suspect these questions remain unanswered or
even unposed by those currently making policy.

For now, we have to go with what we can surmise not just from how Egypt is
handling DST in 2016, but also how DST was handled in recent years like
2014 and 2010.

Dave: I will add that if you are only seeing two transitions in Egypt for
2017–2019 and 2039–2051 with your Perl parser, that is a bug. With 2016e,
you should be seeing four transitions in those years.

--
Tim Parenti
sent from my Android phone
On 16 Jun 2016 11:46, "Frank Bean" <macbean at gmail.com> wrote:

> Just to point out.  Egypt was not observing dst when Ramadan started.
> While phones and computers changed, along with international flight
> schedules, the official time was still just +2.
> On Jun 16, 2016 5:31 PM, "Tim Parenti" <tim at timtimeonline.com> wrote:
>
>> I'm only counting four transitions per year in your output (eight lines)
>> and, yes, this is expected.
>>
>> This year, Ramadan is approximately 5 June to 5 July. Because it moves
>> forward ~11 days per year, as it moves earlier in the spring in 2017
>> through 2019, it remains wholly within our predicted DST period from
>> late-April through late-October. Since Egypt has tended to suspend DST for
>> Ramadan in the past, this nominally requires four clock changes per year:
>> one to spring forward, one to suspend for Ramadan, one to return after
>> Ramadan, and one to fall back.
>>
>> In 2020–2022, Ramadan does not overlap in this way, and so DST is simply
>> delayed by a few weeks until after Ramadan, then in mid-spring, ends. Our
>> six-month predicted DST period is then unaffected by Ramadan for several
>> years as it moves through the winter months, before it is impinged upon
>> once again. In 2036–2038, it merely advances the end date by a few weeks
>> while Ramadan is in mid-autumn, but as it progresses forward, beginning in
>> 2039, it is once again wholly within the late-April to late-October period,
>> and four transitions once again become necessary to reflect Egypt's past
>> practices.
>>
>> Note that, just after tzdata 2016e was released a discussion was started
>> as to whether Egypt will actually observe all four transitions in years
>> such as 2017–2019 and 2039–2051, or whether they will choose to observe it
>> only on one side of the holy month or the other:
>> http://mm.icann.org/pipermail/tz/2016-June/023801.html
>>
>> We don't yet know anything for sure about how this will be handled,
>> though… so from historical evidence, this remains our best guess for now.
>>
>> --
>> Tim Parenti
>> sent from my Android phone
>> On 16 Jun 2016 10:53, "Dave Rolsky" <autarch at urth.org> wrote:
>>
>>> On Thu, 16 Jun 2016, Dave Rolsky wrote:
>>>
>>> Here's a snippet of "zdump -v Africa/Cairo" with the latest changes:
>>>>
>>>
>>> I then realized I hadn't installed the latest tzcode. However, even with
>>> the latest version I still see 3 changes per year in Africa/Cairo starting
>>> in 2039.
>>>
>>> Is that really what's intended?
>>>
>>>
>>> Cheers,
>>>
>>> -dave
>>>
>>> /*============================================================
>>> http://VegGuide.org               http://blog.urth.org
>>> Your guide to all that's veg      House Absolute(ly Pointless)
>>> ============================================================*/
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20160616/3ed76ee4/attachment.html>