[tz] FW: [Ext] The TZ Coordination

[Milamber]

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/ba6ca163/attachment.html>