一直以来应用Linux也就是随便的写点程序，构建一下服务器，很少关注一个基本的设置——时区。我相信大部分的爱好者们都是如此的，我们生活在一个地方，一个国家，一个地区，至少不会频繁改变。so...我们的机器时间设置是很少变化的，再加上现在很多情况下都有UTP——时间网络同步协议了，更不要说去改变时区。
然而对于一个应用Linux作为平台的产品而言，它却是可能会被改变时区的，即便机会不多，但对于设计人员、工程师、项目经理而言，这一部分不容忽视。于是，在第二次遇到这个问题的时候，我选择将它彻底弄清楚，所以有了这样一篇记录。问题的描述是这样的：我们可以使用time调用获取当前的时间，注意，这是以UTC表示的机器时间——自1970年1月1日0点以来的秒数，接着我们用localtime调用可以将time获取的时间转换为本地时间，从UTC转换到本地时间会依靠时区信息进行调整。对于一个daemon进程而言，如果每隔一段时间用time和localtime调用就可以定期获取当前时间的数值，但是如果在这个期间发生了时区设置转换会怎样呢？
或许你会觉得，那一定会出大问题——时区变了，localtime也会出现很大的调整。嗯，接下来的结论就是后续的程序需要小心处理这种变化......
很不幸，我们的感觉是错的，如果时区的设置变化了，localtime转换的时间依然与之前没有什么不同，除非程序再次启动。Linux的时区设置通过几个不同的途径完成。一方面可以通过设置环境变量TZ来指定时区，例如TZ=Asia/Shanghai，可以将时区指定为上海所在的时区，时区的配置出现在/usr/share/zoneinfo/Asia/Shanghai文件当中（Redhat环境）；如果没有指定TZ环境变量，那么缺省的时区配置文件可以用/etc/localtime来获得，这个文件可能是一个符号链接指向真实的文件，也有可能就是将/usr/share/zoneinfo下的文件复制过来达到所要的结果。由于环境变量由各个进程组单独继承，那么在设置时区之后很难改变其他进程组的环境变量，所以一般的系统很少直接设置TZ环境变量，而是由/etc/localtime文件来指示时区位置。
既然如此，为什么设置了时区以后，已经运行的daemon程序在使用localtime函数调用时没有使用新时区呢？这个可以通过glibc的源码来回答。localtime等涉及到本地所在时区的函数在调用的时候会先调用tzset这个函数，这一点可以通过tzset函数的manpage看出来。tzset完成的工作是把当前时区信息（通过TZ环境变量或者/etc/localtime）读入并缓冲。事实上tzset在实现的时候是通过内部的tzset_internal函数来完成的，显式的调用tzset会以显式的方式告知tzset_internal，而单独调用localtime的时候是以隐式的方式告知tzset_internal，前者将强制tzset不管何种情况一律重新加载TZ信息或者/etc/localtime，而后者则是只有在TZ发生变化，或者加载文件名发生变化的时候才会再次加载时区信息。因此，如果只是/etc/localtime的内容发生了变化，而文件名"/etc/localtime"没有变化，则不会再次加载时区信息，导致localtime函数调用仍然以老时区转换UTC时间到本地时间。
结论：对localtime的反复调用，如果要考虑时区变化的因素，最好显式的调用一次tzset。或许今后的glibc库会修正这个bug？至少我在glibc-2.3.5和2.4的版本上还看到这个问题。
阅读(1872) | 评论(0) | 转发(0) |
