这两天被时间问题搞得有些头晕,不过也好,把以前不甚清楚的部分又多搞明白了点儿,这样的知识积累效率确实是低了点儿,只能用聊胜于无来安慰自己了。
常常看见UTC和GMT,可对于他们的确切含义确是一知半解,这也不能完全归于我们的懒惰,因为世界上未知的东西太多,如果要求每项都很清晰,那不仅是强人所难的,更是对于时间的浪费,为什么不把有限的精力投入到更有价值的地方去呢?所以,我们对于这些知识可以选择推迟,也就是说用到的时候再去纠缠。闲话少说,当下就解释一下这两个缩写:
- GMT:Greenwish Mean Time,中文意思为格林尼治时间,也就是在位于格林尼治天文台的本初子午线上测得的时间,它是世界时间的参考基准,其他时区的时间都是以其为参考计算所得。
- UTC:Coordinated Universal Time,中文意思就是协调世界时,按理来说缩写成似乎CUT更加合适些。她使用精确的原子钟来作为时间基准,很多时候他和GMT是通用的。
在UNIX/Linux系统上,引入了计算机纪元(Epoch),也就是UTC1970年1月1日0时0分0秒。Linux内核中所保存的时间就是相对于这个纪元的绝对时间值。在Linux内核启动的时候,它会从计算机硬件的时钟里读取当前的时间值,并转化成相对于计算机纪元的绝对时间,这个时间也就是我们通常所说的系统时间。也正是这个时间维系了计算机系统所有和时间相关的部分,如文件的修改时间,访问时间等。不难发现,对于Linux内核来说,他使用的是相对UTC时间的偏移量作为时间的度量,也就等同于他用的是UTC计时。我们用系统调用time和gettimeofday取得的时间都是系统时间。
Linux系统也支持时区的概念,通常你只需要在目录/usr/share/zoneinfo/下找到以你所在的时区中的地址命名的文件,拷贝为/etc/localtime或者建立到它的符号链接即可。之后你就可以用date命令查询本地时间了。
除了系统时间,Linux系统还有一个命令hwclock能取得计算机的硬件时间,并且能够通过它同步系统的硬件时间和系统时间。硬件时钟通常保存的是UTC时间,而非本地时间,这样做是安全合理的。虽然硬件时钟也能保持本地时间,但是并不推荐这样做,因为Linux内核启动的时候就是按照UTC来读取其值的,虽然系统的启动脚本中都会有按照用户的配置将硬件时间同步到系统时间的一段代码,但是从内核读取硬件时间到脚本同步系统时间这段时间内的一些操作也有可能对系统产生伤害。
探索的过程还有一段小插曲:
gentux work # date
2007年 02月 28日 星期三 22:25:52 CST
gentux work # date -u
2007年 02月 28日 星期三 14:25:54 UTC gentux work # hwclock --utc
2007年02月28日 星期三 22时26分01秒 -0.381929 seconds gentux work # hwclock --local
2007年02月28日 星期三 14时26分12秒 -1.027767 seconds
|
乍一看,这不是错了么?date和hwclock的结果怎么颠倒了?折腾了半天才从hwclock的man页中找到了答案,原来hwclock的--utc和--local是指对于硬件时钟中的值是按照utc还是按照local来进行解释,按照date那样进行类比是不对的,这个时候经验再次欺骗了我们。hwclock命令还有保存命令参数的习惯,稍不注意也能让你晕头转向:
gentux work # hwclock
2007年02月28日 星期三 22时31分17秒 -0.874955 seconds gentux work # hwclock -u
2007年02月28日 星期三 22时32分27秒 -0.383762 seconds
|
两者的结果怎么一样呢?这完全是因为最后一次的--hctosys操作用了--utc参数的结果。怎么都感觉这样的设计有些别扭。
至于其他的一些C API或者是命令的使用,参照系统的man页都能解决了。例如:man 7 time和man 2 time等,不要忘了看最后的SEE ALSO部分哦!
和时间相关的还有夏令时(Daylight Saving Time,缩写为DST),因为其已经基本废除,且不怎么常见,对于其的理解还可以继续推迟啦!
阅读(1832) | 评论(3) | 转发(0) |