[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.html>
More information about the tz
mailing list