从用zabbix到现在，一直为它的时间所困扰。在服务器上的系统时间和web
frontend上graph的横轴时间总对应不上，还有存储到mysql数据库中的clock值。之前也写了两篇关于zabbix时间的总结，但现在发现之前的认知很多都是错的。现在把到目前为止认为正确的东西，总结一下。
0.首先服务器上的系统时间要设置正确。不知道怎么搞的，我的服务器主机上的时间不对，直接比当地时间超前了8小时。悲剧。
1.zabbix系统的时区只与/etc/localtime有关。如果用/usr/share/zoneinfo/下面的某个时区文件(比如我用的Aisa/Shanghai)覆盖/etc/localtime，那么zabbix的系统时区就是相应的localtime(我的就是CST了)。如果不覆盖/etc/localtime，则zabbix就是采用UTC时间。这个可以通过敲入date命令看出来。
(网上也查了很多资料，关于linux系统时区的设置。比较多的是说与/etc/sysconfig/clock文件里的“UTC=true、false”有关。但zabbix的clock文件里边没有“UTC=true、false”，而且自己给加上这么一行也没用。而且与clock文件里的hwclock=--localtime无关系。即便=--localtime，如果不覆盖/etc/localtime，用date命令显示的仍是UTC。)
2.使用虚拟机时，真正的硬件时钟是server(也就是真实主机)上的硬件时钟。虚拟机启动时应该是读取server的硬件时钟，然后根据虚拟机系统的timezone设置来设定系统时间。在虚拟机上执行hwclock
-w命令并不会影响server的硬件时钟(在esxi4.0上部署zabbixappliance的环境下是这样)。虚拟机上的硬件时钟是假的，你把它设成多少，系统重启后它就变成多少，但这个值并不会影响虚拟机的系统时间，影响虚拟机系统时间的是server上的硬件时钟，就是coms里的值。
3.如果系统是utc时间，那么它的date与date
-u的值是相等的，且比server上的时间滞后8小时；如果系统时间是CST，那么它的date值与server时间相等，date
-u比date值滞后8小时。另外，与真假值无关，如果系统是utc时间，那么它的以下几个值是都相等的：
hwclock，hwclock -r，hwclock -u，hwclock
--localtime；如果系统时间是CST，则hwclock -u比其他三个时间滞后8小时。
4.zabbix数据库里的clock值为utc时间，与系统时区无关。也就是date
-u的时间。
5.mysql中from_unixtime()返回的值与mysql数据库所在系统的时区有关！！！如果系统是CST，则返回的结果会比utc时间再加上8小时！！
6.(C#中的方法)以你当地时间记为T，减去1970-1-1
0时，得到的timespan.Ticks/10000000，得到的结果就是unix
timestamp，也就是utc秒数。这个utc秒数记为A的话，在mysql中调用from-unixtime(A)，则：
如果mysql所在系统是utc时间，那么返回的结果就是你的当地时间T；
如果mysql所在系统是CST时间，则返回的结果比T超前8小时！！
也就是用上述(c#)方法计算出的A，比unix
timestamp真值超前了8小时。正确的值应该是A再减掉8小时的秒数！！
7.zabbix
web-frontend显示的graph的横轴时间确实与/etc/php5/apache2/php.ini文件中的timezone的值有关。要设成你所在的时区才能使graph的横轴时间与你的当地时间保持一致。无论zabbix系统是utc还是cst还是别的，php.ini中的timezone都要设成你所在的时区。而且graph的横轴时间与/etc/php5/cli/php.ini里的timezone无关。(但不知道cli里的timezone关系到什么时间)。
