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@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) ============================================================*/

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@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@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@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) ============================================================*/