前言
在工作中，每周都会遇到一些问题，这些问题在大家工作中可能会有许多共性，于我也是一种经验的积累小结。我觉得花一些时间整理一下，跟粉丝读者们分享一下日常工作遇到的问题，这是一个很好的互动和文章分享的痛点。
这是第四篇, 下面看问题。
系统时间更改导致的问题
修改系统时间是一个不是常用的功能，但是又是很必须的。看起来很简单的系统时间的修改，也出了好几个问题。
rpc超时
修改系统时间，本身使用的是一个rpc调用，rpc使用超时机制的，就是在指定时间内如果执行函数没有返回，那么rpc就认为超时失败了。这个问题在前面的文章中讲过，具体可以看这篇文章 超时实现-sysrepo笔记(8)
dhcp接口ip失效
同样的，接口配置了dhcp方式获取地址，由于修改了系统时间为未来的时间，导致dhcp的租期过期，接口自动释放了ip地址。相当于就是没有地址了。这样子，网络就不通的。网络不通算是一个挺大的问题吧，在web上面修改个时间，然后网络就断开了，无法连接了。
这个问题修改也简单，在修改ip的时候，还得触发dhcp续租。
rpc返回时间与系统时间不一致
这个是又在rpc返回是使用的python代码，就是time模块获取时间。当系统时间更改之后，其实python并没有立刻同步到系统的时间，这样就导致了，rpc返回的时间跟使用date命令查看到的时间不一致。
这个问题只需要通过python调用date命令，获取返回结果就可以解决。
系统时间修改之后，设备重启时间不正确
操作系统的时间，有软件时间和硬件时间，平常使用date设置和获取的时间都是软件时间。在设备重启之后，系统时间会同步为硬件时间，这就导致了问题。
也就是在修改系统时间的同时，需要同步修改到硬件时间，调用命令hwclock -w。
系统时间修改之后，如果不同零时区，设备重启后时间会快几个小时
在上面那个问题修改之后，当当前时区是UTC时，功能正常。但是如果当前时区不是UTC时，重启之后，发现时间会快几个小时。这个就涉及到了时区跟时间轴的问题。
随着时区的不同，即使显示的时间是一致的，实际上它那个时间轴却是不同的。上一个问题中，使用hwclock -w命令，实际是把时区转换后的时间同步给了硬件时间，但是硬件时间重启后是没有时区概念的，就是认为是零时区。就是你保存了1000进去，1000对应的是8时区的。重启后，它又给设到软件时间1000， 告诉你这个是0时区的时间。然后，你软件时间是8时区，最后显示出来的时间是1000 + 8小时。
这个问题修改，需要在同步的时候，指定为0时区时间同步， 调用命令hwclock -w -u.
更多
系统软件运行的时候，很多功能都是假定时间不变的基础上运行的。在修改了时间之后，系统实时时间就变了，很容易就导致了异常。只是这个时间更改是一个低频事件。
最开始开发这个功能的时候，看了深信服产品web端的效果，发现修改个时间，都要求系统要重启，感觉很暴力。看来是人家踩过了不少坑，最后采用了最行之有效的重启大法，虽然重启导致了业务的中断，但是这个是低频事件，重启可以解决许多未知的问题。系统时间的更改是一个还蛮有风险的动作。
时间更新除了手动修改外，还可以使用ntp自动同步，这里就不多说了。
行动，才不会被动!
欢迎关注个人公众号 微信 -> 搜索 -> fishmwei，沟通交流。