Linux time zone settings and modifications under C language (iii)

All the while, Tzset seems to take effect only when it's initialized, and it doesn't work when Tzset calls multiple times.
Today a little in-depth search of the glibc in the implementation of the Tzset, found that is not the case, its real implementation is to be resolved every time. Why it is mistaken that Tzset is invalid because of the local process's environment variables and global environment variables.
The implementation of the specific tzset is tzset_internal, in this function, the basic idea is:
1, first check the environment variable TZ environment variables exist, effective
2, according to the TZ environment variable to get the specified time zone file path and file name
3, save the current use of this environment variable TZ
4, try to read the data file, here's the data file Im file Tzfile, note that its data is in a fixed format.
5, in the above Step4, will be based on tzfile documents, to refresh the timezone and daylight. After the resolution of the Tzfile file succeeds, a variable named __use_tzfile is also set to 1
6, according to the results of the above analysis, according to whether __use_tzfile to determine whether the need to continue, if not resolved tzfile success, then judge TZ is valid, invalid refresh Tzname value, think the default use UTC time.
7, if the above operation process, found tzfile analytical failure, and TZ is effective, you need to finally to resolve the TZ environment variables, this case TZ environment variable is there is time, its time is used to set summer in the winter, that is, daylight saving times.
In the process of parsing, you can see that it is consistent with the description of the Man Handbook.
The three formats for TZ environment variables are clearly stated in the manual
(1) In the local time zone when there is no summer in winter, you can use the following format: STD offset
The name of the time zone, which is represented by an STD, is three letters. The offset string indicates how much time you need to add (or subtract) to the UTC time, the hour is 0~24, and the minute is 0~59
(2) The second format is used for summer and winter time, and its format type is: STD offset DST [Offset].start[/time].end[/time]
Note that there are no spaces in the above format. The initial STD and offset indicate the standard time zone. DST and offset indicate the time zone name and offset of the corresponding summer and winter periods. If offset is ignored he defaults to the first one hours of standard time.
The Start field marks the time when summer is in effect, and the End field indicates when the change is restored to standard time.
These fields may have the following two formats:
The Jn mark is Julian Day with N to denote 1~365. February 29 will not count into days, even in leap years
n indicates that Julian Day uses N to denote 0~365. In leap year February 29 accounting into the days.
MM.W.D Specifies the D (0~6) days of the 1~5 week of the M (1~12) month. 0 days means Sunday.
A Time field indicates when the local time becomes effective and changes to another. If omitted, the default is 02:00:00
For example, the standard New Zealand time is NZST, which is 12 hours before UTC, while summer and winter time is 13 hours before NZDT,UTC time, the effective interval is from the first Sunday of October to the land of March three Sundays, and this modification time occurs at the default 02:00:00
(3) A third format used to give file information for a given time zone file:: [filespec]
If the above file description information filespec is ignored, the file that reads the time zone information will be the localtime file in the system time zone directory, and this directory is now generally/usr/share/zoneinfo
. Its file format is tzfile format. Filespec will not start with/, and the file description information is relative to the system time zone directory, for example, still with New Zealand example:
tz= ":P Acific/auckland"


Now understand the TZ environment variable settings, as well as the implementation of the Tzset file principle. Then why is it not valid to use export to change the TZ environment variable and then call Tzset to refresh the time zone information.
(The test example of Tzset in the actual running glibc is effective ...) ）
The reason is:
The environment variable exported by export is an environment variable that is session.
Putenv, however, is an environment variable that is an object of a process.
Based on the above example test, write the shell script (export call exported) and the program (PUTENV) contrast, found that the result is really the two do not interfere with each other, even if the two environment variable names are the same!!!




The conclusion is:
1, if you want to set the time zone, according to the implementation of GLIBC, it is best to use the time zone file changes, or to establish links to localtime time zone files, or power loss before the modification will certainly be lost.
2, Tzset call Refresh to get the timezone is actually valid, and in order to prevent other programs from changing the time zone, if the running process is a time zone sensitive, it is important to do uninterrupted refresh.
3, attention to environmental variables TZ time zone information interference, environment variables can specify the time zone, or can be a specified time zone file.