从Windows/Linux系统时间冲突问题出发,讲述操作系统-BIOS以及时间的操作

写作动机

  双系统是不少人喜欢的方式,但安装双系统之后一般会出现两个系统时间不一样的问题,刚开始用双系统的时候也没怎么在意,就是装上后在网上找找相关解决方法,复制粘贴代码完事儿。但是次数多了就有点烦了,每次都这样搞问题倒是解决了但是不知道原理。

  最近几次发现解决方法发生了改变,和之前的方法不一样了,于是打算一探究竟。如果你想了解原理请仔细阅读,句句都是重点。

  注意:以下并没有解决问题的实际代码,因为本文章是讲原理的!

术语解释

  设备上的时间:一是系统时间(Local time),一是硬件时间(RTC)。系统时间指操作系统的时间,可以认为就是我们看到的时间;硬件时间指 BIOS 中的时间,这里不解释 BIOS 是啥了(你可以认为是和操作系统同时且独立运行的另一个系统)。也就是说这俩可以有自己的不同的时间。

  真实的时间:世界统一时间(UTC),本地时间(中国=CST/UTC+8)。世界统一时间指地球上所有时间都以一个地方的时间为基准,本地时间指在不同的地区根据世界时间作调整。具体怎么个算法不懂的自己去搜。

问题产生原因

  真实世界的时间不会出现问题,当我们知道中国处于东八区时世界时间就和本地时间绑定了,有 [本地时间=世界时间+8] 。

  系统时间和硬件时间就可能出现问题,系统时间虽然可以从网络同步,但在未联网时也需要显示时间啊,所以操作系统启动时需要读取硬件时间(BIOS中的时间一直在自同步)。

  问题就在于这两个系统对硬件时间的看法不一样 : ) 。Windows 认为硬件时间是本地时间,也就是取出来直接显示就对了;而 Linux 则认为硬件时间是世界时间,取出来再根据时区进行 “+8” 操作之后再显示才对。

  根据以上描述可以推断,双系统设备中的 Linux 系统时间将比 Windows 系统中的时间快八小时。

  另外如果你的设备上并不是这种情况,请根据以上原理自行查找原因,并可参考如下所述的解决方案自行操作。

两大主流解法

  一为修改 Linux 系统中的标准

    较早版本中通过修改配置文件,新版本中通过 “timedatectl” 进行控制,最终结果其实也是形成了一个配置文件,以便在以后系统取时间时使用正确的算法。

    其它文档说这个版本界限在Ubuntu中是 16.04 ,请自测。

  一为修改 Windows 系统中的标准

    通过修改一个注册表参数来控制其系统时间,原理应该也是和 Linux 系统中一样的吧。

  这两种修改方法都可以使两个系统显示的时间是本地时间,其原理是统一这两个系统对于硬件时间的认知标准。

  我不建议修改 Windows 的配置文件,不是我认为 Windows 的标准是对的,而是觉得 Linux 更适合折腾。

偏门解法

  在查这个问题的时候发现了一些有意思的解法,其中有一个是修改系统中的时区。

  比如 Linux 系统中使用了 [世界时间+8] 来计算显示错误,那么是因为其认为这里是 “UTC+8” 所以应该显示 [世界时间+8] 之后的时间;解决方案是设置 Linux 中时区为 “+0” 的时区,那么显示结果为 [世界时间+0]。恕我直言,这解法真是……太可爱了 0.0

  按照上述解法的思维,我也可以先在 Linux 系统同步时间至正确,然后再将 Windows 系统的时区设置为 “+16” 的时区,也可以使两个系统都显示正确,可能因为实际没有 “+16” 的时区,不然还真有这种解法呢。

一些思考

  操作系统启动后都需要去读取硬件时间,但硬件时间到底应该是世界时间还是本地时间呢?这个要真要有个能说了算的那一定是 BIOS 的创造者了,不过估计当时可能也没考虑到这个问题,毕竟时间这个东西也不是 BIOS 的主要功能,至于现在不同操作系统能否统一标准也不是我能说了算的……

  另外其实任何系统都完全有能力解决这个问题,但不知道为啥都视而不见

  这里斗胆建议一下 Linux 系统下可用的解决方案:

    一可在系统安装(假设Linux后安装)时,时区选择后让用户确认真实时间是 [硬件时间] 还是 [硬件时间+时区] ,再根据选择修改配置文件

    二可在系统已经完成安装的情况下,当用户多次手动校准时间(手动设置或网络校准)时,计算校准前后时间差是否和时区值基本相等,以此判断硬件时间是否是本地时间

最后

  知识还是那么些知识,其它技术文档里基本都能找到,我只是用自己的思维重新表述一下,一来做个笔记,再者希望可以帮助到别人

  原创文章,转发请注明

 

版权声明:本文为sxdc原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/sxdc/p/12773781.html