FW: [Ext] The TZ Coordination
Dear Paul, Please see the note below from our colleagues in Morocco regarding the upcoming timezone change for Morocco. Best regards, Naela Naela Sarras Director, IANA Operations ICANN From: EL MAAYATI Afaf <afaf@anrt.ma> Date: Wednesday, May 27, 2020 at 12:01 PM To: Naela Sarras <naela.sarras@iana.org> Cc: BENLEMLIH Hamida <benlemlih@anrt.ma> Subject: [Ext] The TZ Coordination Dear Naela, I hope this email finds you well, safe and healthy. Actually, I have a request concerning the configuration of the Time-Zone for Morocco. In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it’s mentionned that a program will be running to implement the transition dates: [cid:image001.jpg@01D6342E.01C70B10] Currently we are implementing GMT and we will move to GMT+1 next Sunday, May 31. So, if possible, would you please help to get in touch with Mr. Paul Eggert, in order to have the procedure to notify IANA officially, from a governmental source, with the changes of TZ in Morocco. Thank you in advance for your feedback and for your habitual support. Best Regards, Afaf ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.
From Afaf El Maayati (2020-05-27):
In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it’s mentioned that a program will be running to implement the transition dates
That commentary refers to a program that I ran on April 14; it predicted daylight-saving transitions for Morocco for the years 2021 through 2087, and I installed those predictions into tzdb 2020a. We don't know now whether those predictions are correct, since the government of Morocco hasn't published plans for 2021 and later and it might change its mind before next year. Even so, the tzdb tradition is to predict plausible transitions that are more likely to be correct than a prediction of no transitions at all.
we will move to GMT+1 next Sunday, May 31.
Yes, that transition is in tzdb 2020a (the current tzdb release), so tzdb should not need any changes for it. Currently, devices based on out-of-date tzdb releases are off by an hour for Morocco; these devices should start being correct on May 31. Devices based on tzdb 2020a should be correct both now and after May 31. PS. Of the devices I have ready access to, many are out-of-date and are therefore showing incorrect time for Morocco because it takes more than a few weeks to propagate tzdb changes via manufacturers and suppliers to the billions of devices on the planet. My up-to-date devices are running: * Android 10 with APEX updates from Google Play Store * iOS 13.3.1 * macOS 10.14.6 * Ubuntu 18.04.3
Paul Eggert said:
We don't know now whether those predictions are correct, since the government of Morocco hasn't published plans for 2021 and later and it might change its mind before next year. Even so, the tzdb tradition is to predict plausible transitions that are more likely to be correct than a prediction of no transitions at all.
Would this be a good opportunity to engage with the government of Morocco to encourage them to give more warning? -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
* Clive D. W. Feather:
Paul Eggert said:
We don't know now whether those predictions are correct, since the government of Morocco hasn't published plans for 2021 and later and it might change its mind before next year. Even so, the tzdb tradition is to predict plausible transitions that are more likely to be correct than a prediction of no transitions at all.
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. They would have to redefine the criteria to something based exclusively on astronomical calculations, probably giving up the alignment with Ramadan. I don't know if this would be feasible.
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. Admittedly there are obstacles to getting all this to work. That being said, I suspect that the obstacles here are administrative, not religious or technical. We needed a tzdb 2020a because in 2019c I had predicted a tighter bound around the actual Ramadan, whereas the Moroccan authorities evidently wanted a looser bound. That is, Ramadan ended May 23 in Morocco, and tzdb 2019c had predicted May 24 for the spring-forward transition whereas the Moroccan government decided on May 31. PS. In about three hours the discrepancy will become moot, as Morocco will do its end-of-Ramadan spring-forward and after that the 2019c clocks will agree with the 2020a clocks.
* 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. A rule like this would ensure that Eid still uses the same time as Ramadan in every year, which is likely what people expect.
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.
Forgive me if this is in any way ignorant, but why must the DST transitions align so precisely with Ramadan? 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@iana.org> on behalf of Milamber <milamberspace@gmail.com> Sent: Sunday, May 31, 2020 7:03:50 AM To: Florian Weimer <fw@deneb.enyo.de>; Paul Eggert <eggert@cs.ucla.edu> Cc: Time zone mailing list <tz@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.
Astrologers have been significant contributors to this list.
On May 31, 2020, at 1:25 PM, Matt Johnson-Pint <mj1856@hotmail.com> wrote:
Forgive me if this is in any way ignorant, but why must the DST transitions align so precisely with Ramadan? 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@iana.org> on behalf of Milamber <milamberspace@gmail.com> Sent: Sunday, May 31, 2020 7:03:50 AM To: Florian Weimer <fw@deneb.enyo.de>; Paul Eggert <eggert@cs.ucla.edu> Cc: Time zone mailing list <tz@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.
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@iana.org> on behalf of Milamber <milamberspace@gmail.com> *Sent:* Sunday, May 31, 2020 7:03:50 AM *To:* Florian Weimer <fw@deneb.enyo.de>; Paul Eggert <eggert@cs.ucla.edu> *Cc:* Time zone mailing list <tz@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.
There is also the Eid al-Fitr festival at the start of the next month Shawwal which may last from 1-5 days, during which for some reason they typically also do not want a time change, although I would think that an opportune period. On 2020-05-31 12:57, Milamber wrote:
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?
On Sunday, May 31, 2020 7:03:50 AM, Milamber wrote: On 5/31/20 12:09 PM, Florian Weimer wrote:
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.
-- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in IEC units and prefixes, physical quantities in SI.]
On 5/31/20 10:25 AM, Matt Johnson-Pint wrote:
why must the DST transitions align so precisely with Ramadan? 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?
They don't need to align exactly, and they aren't aligned exactly in either 2019c or 2020a. Instead, Morocco approximates Ramadan by doing transitions the weekend before Ramadan starts and the weekend after it ends. 2019c guessed weekend brackets around Ramadan that were too tight. I loosened the brackets in 2020a by guesswork, and Milamber's email says that my guesses were not quite loose enough; hence today's patch.
On 5/31/20 7:03 AM, Milamber wrote:
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.
Thanks for the info. I installed the attached patch to change the predictions accordingly. Of course these predictions are somewhat fanciful if the Moroccan government itself doesn't know when the transitions will be.
Hi Paul, Seems look good for the patch. Thank you. I hope that will match with the next decisions of Moroccan Government for the next years. Regards, Milamber CC. ANRT (national telecom regulator agency of Morocco) CC. Naoufal S. from first telco operator in Morocco On 5/31/20 11:23 PM, Paul Eggert wrote:
On 5/31/20 7:03 AM, Milamber wrote:
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. Thanks for the info. I installed the attached patch to change the predictions accordingly. Of course these predictions are somewhat fanciful if the Moroccan government itself doesn't know when the transitions will be.
Dear Paul, I hope this email finds you well, and in good health. Actually, I'm getting back to you about next transition to GMT in Morocco on Sunday 11 April at 03 AM. Please find here the official annoncement, done by the government: - https://www.maroc.ma/fr/actualites/ramadan-retour-lheure-legale-au-maroc-gmt.... - https://www.mmsp.gov.ma So, I wonder if you could please confirm that the tansition, in IANA Time Zone Data Base, would be effective as annouced (Sunday 11 April at 03 AM). Thank you in advance for your feedback and for your habitual support. Best Regards, Afaf EL MAAYATI National Telecommunications Regulatory Agency (ANRT) .ma ccTLD Morocco -----Message d'origine----- De : Paul Eggert <eggert@cs.ucla.edu> Envoyé : jeudi 28 mai 2020 01:48 À : EL MAAYATI Afaf <afaf@anrt.ma> Cc : Naela Sarras <naela.sarras@iana.org>; Time zone mailing list <tz@iana.org>; BENLEMLIH Hamida <benlemlih@anrt.ma> Objet : Re: [tz] FW: [Ext] The TZ Coordination From Afaf El Maayati (2020-05-27):
In the Database file: ftp://ftp.iana.org/tz/tzdb-2020a/africa, it’s mentioned that a program will be running to implement the transition dates
That commentary refers to a program that I ran on April 14; it predicted daylight-saving transitions for Morocco for the years 2021 through 2087, and I installed those predictions into tzdb 2020a. We don't know now whether those predictions are correct, since the government of Morocco hasn't published plans for 2021 and later and it might change its mind before next year. Even so, the tzdb tradition is to predict plausible transitions that are more likely to be correct than a prediction of no transitions at all.
we will move to GMT+1 next Sunday, May 31.
Yes, that transition is in tzdb 2020a (the current tzdb release), so tzdb should not need any changes for it. Currently, devices based on out-of-date tzdb releases are off by an hour for Morocco; these devices should start being correct on May 31. Devices based on tzdb 2020a should be correct both now and after May 31. PS. Of the devices I have ready access to, many are out-of-date and are therefore showing incorrect time for Morocco because it takes more than a few weeks to propagate tzdb changes via manufacturers and suppliers to the billions of devices on the planet. My up-to-date devices are running: * Android 10 with APEX updates from Google Play Store * iOS 13.3.1 * macOS 10.14.6 * Ubuntu 18.04.3 [https://www.anrt.ma/images/ANRT-Signature.jpg] ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.
On 3/31/21 9:17 AM, EL MAAYATI Afaf wrote:
So, I wonder if you could please confirm that the tansition, in IANA Time Zone Data Base, would be effective as annouced (Sunday 11 April at 03 AM).
Yes, for tzdb 2018h and later; see the following. I hope our prediction for May will be correct as well. $ zdump -V -c 2021,2022 Africa/Casablanca Africa/Casablanca Sun Apr 11 01:59:59 2021 UT = Sun Apr 11 02:59:59 2021 +01 isdst=0 gmtoff=3600 Africa/Casablanca Sun Apr 11 02:00:00 2021 UT = Sun Apr 11 02:00:00 2021 +00 isdst=1 gmtoff=0 Africa/Casablanca Sun May 16 01:59:59 2021 UT = Sun May 16 01:59:59 2021 +00 isdst=1 gmtoff=0 Africa/Casablanca Sun May 16 02:00:00 2021 UT = Sun May 16 03:00:00 2021 +01 isdst=0 gmtoff=3600
Dear Paul, Thank you very much for your kind feedback. Yes, we would return to GMT+1 on May 16 (02:00) Best regards, Afaf EL MAAYATI -----Message d'origine----- De : Paul Eggert <eggert@cs.ucla.edu> Envoyé : mercredi 31 mars 2021 18:31 À : EL MAAYATI Afaf <afaf@anrt.ma> Cc : Naela Sarras <naela.sarras@iana.org>; Time zone mailing list <tz@iana.org>; ma <ma@anrt.ma> Objet : Re: [tz] FW: [Ext] The TZ Coordination On 3/31/21 9:17 AM, EL MAAYATI Afaf wrote:
So, I wonder if you could please confirm that the tansition, in IANA Time Zone Data Base, would be effective as annouced (Sunday 11 April at 03 AM).
Yes, for tzdb 2018h and later; see the following. I hope our prediction for May will be correct as well. $ zdump -V -c 2021,2022 Africa/Casablanca Africa/Casablanca Sun Apr 11 01:59:59 2021 UT = Sun Apr 11 02:59:59 2021 +01 isdst=0 gmtoff=3600 Africa/Casablanca Sun Apr 11 02:00:00 2021 UT = Sun Apr 11 02:00:00 2021 +00 isdst=1 gmtoff=0 Africa/Casablanca Sun May 16 01:59:59 2021 UT = Sun May 16 01:59:59 2021 +00 isdst=1 gmtoff=0 Africa/Casablanca Sun May 16 02:00:00 2021 UT = Sun May 16 03:00:00 2021 +01 isdst=0 gmtoff=3600 [https://www.anrt.ma/images/ANRT-Signature.jpg] ________________________________ Ce message, son contenu et toutes les pièces jointes sont adressés à l'attention exclusive de leur (s) destinataire (s) et sont strictement confidentiels : ils relèvent de la correspondance privée. Toute publication, utilisation ou diffusion, même partielle, par des personnes autres que les destinataires est interdite et doit être autorisée par l'Agence Nationale de Règlementation des Télécommunications (ANRT, Royaume du Maroc). Si vous recevez ce message par erreur, nous vous prions de le détruire après en avoir informé son expéditeur sans délai. L’ANRT décline toute responsabilité pour toute altération, déformation ou falsification subi par le message et ses pièces jointes au cours de leur transmission. Retrouvez toutes les informations de l’ANRT sur son site Web à l’adresse suivante : http://www.anrt.ma. ________________________________ This message, its content and its attachments are intended for the exclusive use of the named addressee (s) and are strictly confidential. Any copy or other use of this information by persons or entities other than the intended recipient is prohibited and should be authorized by the National Agency of Telecommunications Regulation (ANRT, Morocco). If you have received this communication in error, please delete the material and notify the sender. The ANRT accepts no liability for any alteration, distortion or falsification that may occur during the transmission of this message. All information about ANRT can be found on our website at the following address http://www.anrt.ma. ________________________________ إن هذه الرسالة ومحتواها ومرفقاتها موجهة خصيصا للشخص المرسل إليه وتعتبر سرية وتصنف ضمن خانة المراسلات ذات طبيعة شخصية. ويمنع منعا كليا نشر أو استعمال أو بث، ولو بطريقة جزئية، لهذه الرسالة من طرف أشخاص غير المرسل إليهم ما لم يتم الترخيص بذلك من طرف الوكالة الوطنية لتقنين المواصلات (المملكة المغربية. في حالة ما إذا توصلتم هذه الرسالة عن طريق الخطأ، يرجى منكم العمل على إتلافها فورا بعد إخبار الشخص المرسل إليه بذلك. ولا تتحمل الوكالة الوطنية لتقنين المواصلات أي مسؤولية عن أي تحريف أو تغيير أو تزييف قد يلحق بمحتوى الرسالة أو بمرفقاتها خلال عملية الإرسال. للمزيد من المعلومات، يرجى الاطلاع على الموقع الإلكتروني للوكالة الوطنية لتقنين المواصلات : http://www.anrt.ma.
participants (9)
-
Brian Inglis
-
Clive D.W. Feather
-
EL MAAYATI Afaf
-
Florian Weimer
-
Matt Johnson-Pint
-
Milamber
-
Naela Sarras
-
Paul Eggert
-
Zoid Soft