[tz] FW: [Ext] The TZ Coordination

Milamber milamberspace at gmail.com
Sun May 31 18:57:26 UTC 2020

On 5/31/20 6:25 PM, Matt Johnson-Pint wrote:
> Forgive me if this is in any way ignorant, but why must the DST 
> transitions align so precisely with Ramadan?

Because, during the Ramadan, the Muslims don't eat/drink from the 
sunrise to the sundown, so in Morocco with a GMT+1 timezone, the first 
lunch of the day will be near 08:30 pm (named 'Ftour' - Breakfast). So 
the people (and government) prefer switch back to GMT+0 to have the 
first lunch earlier during this month.

> Would it not be sufficient if the dates for the time change were 
> predictable as long as the switch to GMT occurred sometime before the 
> start of Ramadan and the switch back to GMT+1 occurred sometime after? 
> Is there a political, social, or religious reason why they must be so 
> exactly aligned?
> -Matt
> ------------------------------------------------------------------------
> *From:* tz <tz-bounces at iana.org> on behalf of Milamber 
> <milamberspace at gmail.com>
> *Sent:* Sunday, May 31, 2020 7:03:50 AM
> *To:* Florian Weimer <fw at deneb.enyo.de>; Paul Eggert <eggert at cs.ucla.edu>
> *Cc:* Time zone mailing list <tz at iana.org>
> *Subject:* Re: [tz] FW: [Ext] The TZ Coordination
> On 5/31/20 12:09 PM, Florian Weimer wrote:
>> * Paul Eggert:
>>> On 5/30/20 7:00 AM, Florian Weimer wrote:
>>>>> Would this be a good opportunity to engage with the government of Morocco
>>>>> to encourage them to give more warning?
>>>> My understanding is that at present, they don't know themselves in
>>>> advance.
>>> Yes, I think you're right.
>>>> They would have to redefine the criteria to something based
>>>> exclusively on astronomical calculations
>>> That shouldn't be necessary, as they're using a conservative
>>> approximation; that is, it's OK if their approximation is a bit off
>>> because all they need to do is to bracket the actual Ramadan rather
>>> than predict its Gregorian dates exactly.  If they had an algorithm
>>> they could publish it and we could use it. And it would be
>>> technically feasible for them to have an algorithm; see the
>>> Morocco-prediction code in the tzdb 'africa' file for an example
>>> algorithm.
>> It looks like the algorithm predicted correctly the data of Eid
>> al-Fitr as 24 May, but the derivation of the end date from that is
>> suspicious.  I think it would make more sense if the time change does
>> not happen on Eid itself.
> In Morocco (where I live), the end of Ramadan (arabic month) is follow 
> by the Eid al-Fitr, and concretely it's 1 or 2 day off for the people 
> (with traditional visiting of family, big lunches/diners, etc.). So 
> for this year the astronomical calculations don't include the 
> following 2 day off in the calc. This 2 days have fall in a 
> Sunday/Monday, so it's not acceptable by people to have a time shift 
> during these 2 day off.
> Perhaps, you can modify the (predict) rules for next years : if the 
> end of Ramadan is a (probable) Friday or Saturday (and so the 2 day 
> off is on a weekend), the next time shift will be the next weekend.
>>   A rule like this would ensure that Eid
>> still uses the same time as Ramadan in every year, which is likely
>> what people expect.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20200531/1d0fded7/attachment.htm>

More information about the tz mailing list