DST Morocco, a way to trick NTP server

From several years Morocco have been using GMT without DST, in the past years, our government reactivated the use of DST.

In the first years, the DST was a mess, different periods, starts, ends, so Microsoft tried to release some patches, they were available very late, and in some years, the patches were not public and we had to contact Microsoft directly.

From this year, Morocco DST is same than european one, except that Morocco will revert to GMT during the month of Ramadan and move again to DST after it. As Ramadan is the nineth month in the moon/hijri calendar, there is no way to have a timezone that will change every year and calculate the changes of DST/GMT.

Our problem :

We have 2003 active directory, a third of our LAN with Ubuntu Desktop, the connection with AD is done with centrify. We have also many computers, servers outside AD, and we have almost a hundred of network equipements, switches, routers, firewalls, appliances. We have a Linux NTP server.

In GMT all work fine, AD controllers get their time from Linux NTP server, other equipements and no AD ones get also their time from Linux NTP server.

In DST mode, there is many problems, and as my colleagues are stubborn, they don't understand NTP, and they always force the use of point number 1 :

  1. Remove NTP config from AD controllers, trick their clock to GMT+1 while their timezone is still GMT.

    In this scheme, the clock is no more accurate, the new clock operate in Windows AD environment only. For Linux computers, even they are members of AD, we must install NTP daemon and add our DC in it's configuration

    Information System divided like a civial war, a part with DST without accurate clock; a part with accurate clock without DST, troubleshooting, tracking logs almost impossible.

  2. Leave NTP config on AD controllers, patch the Information System

    It's impossible because there is no such crazy clever patch

    Even I find a patch it won't be available for all products in our Information System, and moreover the patch must have the 2015 version

  3. Leave NTP config on AD controllers, change timezone to GMT+1 like WAT

    Very hard to do it, even in 2003 AD, there is no way to do it from GPO !

    Even it is possible, with Ramadan, we have to revert the whole changes to GMT again, and to activate changes once again after Ramadan

  4. Filling a petition to the Moroccan government, asking them to leave DST time unchanged in Ramadan, and establishing a decree changing work hours from (9h00 to 15h00 GMT mode) to (10h00 to 16h00 DST mode)

I am hoping that you will help me to make the 5th scenario possible :

  1. Absolutely no changes in the Information System, apart tricking our Linux NTP server (Ubuntu 14.04) , making it giving its clients the (universal time + 1) instead of (universal time)

    This scenario will require one change, the clock will be accurate while the Information System will have the DST time by staying in GMT timezone


The problem with tricking the computers is that, while the clock will appear correct, the actual times stored in the system will be one hour wrong. Eventually you will get a timezone update for your operating system, if it is still supported, and then the time errors will appear.

This is how you deal with timezone updates generally (the right way):

For Linux systems, including Linux based NTP servers, you don't need to do anything except to ensure that the tzdata package is kept up to date. This is always updated as far in advance of DST changes as is practical, as it is maintained by the IANA. In fact, it already accounts for Ramadan in 2016, 2017, 2018, 2019... I didn't look any farther.

For Windows systems the issue is more complicated. Microsoft have a poor history of distributing timezone changes in a timely manner, and particularly with Morocco, where in 2014 it distributed a hotfix for the Ramadan DST change three weeks after Ramadan started! In any case, at the moment you should have correct time until Ramadan if you have applied the December 2014 cumulative time zone update. Microsoft states they will distribute a hotfix to account for 2015 Ramadan at a future time. Especially with Microsoft's terrible track record at distributing these updates, you should try to push them out as soon as they are available.

If Microsoft have not made a hotfix available before Ramadan, I would work around the problem by using a GPO to change the system timezone on all Windows systems to GMT, and then change it back at the end of Ramadan. As noted above, Linux systems do not need any correction.

Finally, note that Server 2003 is going end of life and will not receive further updates. This means it won't be possible in any reasonable manner to update its idea of daylight saving time. You should decommission any remaining XP and 2003 systems as soon as possible (not only for that reason, but for all the other reasons).