在最初几年,DST是一个混乱,不同的时期,开始,结束,所以微软试图发布一些补丁,他们可用很晚,并在几年,补丁不公开,我们不得不直接联系微软.
从今年开始,摩洛哥DST与欧洲DST相同,只是摩洛哥将在斋月期间恢复到格林尼治标准时间,之后再次转向夏令时.
由于斋月是月亮/日历中的第九个月,因此无法确定每年都会改变的时区并计算DST / GMT的变化.
我们的问题：
我们有2003活动目录,我们的局域网中有三分之一用Ubuntu Desktop,与AD的连接是用centrify完成的.我们还有许多计算机,AD以外的服务器,我们有近百个网络设备,交换机,路由器,防火墙,设备.我们有一个Linux NTP服务器.
在GMT中,一切正常,AD控制器从Linux NTP服务器获得时间,其他设备也没有AD从Linux NTP服务器获得时间.
在夏令时模式中,存在许多问题,并且由于我的同事很顽固,他们不了解NTP,他们总是强制使用第1点：
>从AD控制器中删除NTP配置,将其时钟设为GMT 1,同时其时区仍为GMT.
在这种方案中,时钟不再准确,新时钟仅在Windows AD环境中运行.对于Linux计算机,即使它们是AD的成员,我们也必须安装NTP守护程序并在其配置中添加我们的DC
信息系统像民间战争一样划分,是没有准确时钟的DST的一部分;一个没有DST的精确时钟的部件,故障排除,跟踪日志几乎是不可能的.
>在AD控制器上保留NTP配置,修补信息系统
这是不可能的,因为没有这样疯狂的聪明补丁
即使我找到了一个补丁,它也不适用于我们的信息系统中的所有产品,而且补丁必须具有2015版本
>在AD控制器上保留NTP配置,将时区更改为GMT 1,如WAT
很难做到,即使在公元2003年,也没有办法从GPO做到这一点！
即使有可能,在斋月期间,我们必须再次将整个变化恢复为GMT,并在斋月后再次激活变化
>向摩洛哥政府填写请愿书,要求他们在斋月期间保持DST时间不变,并建立一项法令,将工作时间从(格林尼治标准时间9点到15点)改为(10点00分至16点00天夏令时模式)
我希望你能帮助我实现第五种情况：
>除了欺骗我们的Linux NTP服务器(Ubuntu 14.04)之外,信息系统绝对没有变化,使其为客户提供(通用时间1)而不是(通用时间)
这种情况需要一次更改,时钟将是准确的,而信息系统将通过停留在GMT时区具有夏令时时间
这就是你通常如何处理时区更新(正确的方法)：
对于Linux系统(包括基于Linux的NTP服务器),除了确保tzdata包保持最新之外,您无需执行任何操作.在实际可行的DST变化之前,它总是更新,如it is maintained by the IANA.实际上,它已经在2016年,2017年,2018年,2019年占据了斋月…我看起来没有更远.
对于Windows系统,问题更复杂.微软及时分发时区变化的历史很差,尤其是摩洛哥,其中in 2014 it distributed a hotfix为斋月DST改变three weeks after Ramadan started！在任何情况下,如果您已应用December 2014 cumulative time zone update,则在you should have correct time until Ramadan时.Microsoft声明他们将在未来分发修补程序以记录2015年斋月.特别是微软在分发这些更新时的糟糕记录,你应该尽快将它们推出.
如果Microsoft在Ramadan之前没有提供修补程序,我会通过使用GPO将所有Windows系统上的系统时区更改为GMT,然后在Ramadan结束时将其更改回来解决此问题.如上所述,Linux系统不需要任何更正.
最后,请注意Server 2003即将结束,不会再收到更新.这意味着无法以任何合理的方式更新其夏令时的想法.您应该尽快停用任何剩余的XP和2003系统(不仅仅是因为这个原因,而是出于所有其他原因).
