As fellow Hoosiers probably know, our fine government has again decided to change timezone laws. With a glorious history of changes being made not just at the state level, but on a county-by-county level, and with the addition of several changes that were implemented, reverted, re-implemented, etc., it has been interesting to keep up with. No one in central Indiana has had to think about changing their clocks since 1970, but those days are gone. Now we get to enjoy the fun that the outlying counties have been having for the last several decades.
Anyway, to get back on topic, the timezone files are generated during the building of glibc and are based on the info in glibc-<version>/timezone/* which are actually taken from ftp://elsie.nci.nih.gov/pub/tzdata<version>.tar.gz. Glibc regularly keeps sync with that tarball. If you live in a county that will be changing timezone rules you may have to find a workaround. Here is what I know so far: - >= glibc-2.3.6 has the updated information so if you run that no changes are needed. - glibc < 2.3.6 requires a workaround or a rebuild, or possibly just copying a compiled timezone from a >=glibc-2.3.6 system Workaround: In many (most? all?) cases, you can use a timezone file for another city. The big three would be New York, Chicago, or Louisville, depending on which county you live in, but this is only a hack. Using another timezone file will make the clock do the right thing from here on, but files saved before then might suddenly have the wrong file creation/modification date (a matter of an hour or two depending on when it was created). The reason for this is that the file is saved in GMT time and the /etc/localtime merely calculates from that point. The timezone file doesn't just set the current time but includes a history of all timezone changes for that file for a given period of time (the stated start time for such records is 1970). This means that if you are in Indianapolis and start using America/New_York, any file created during New York's daylight savings period before April 2nd 01:59:59 (i.e. any summer before this one) will be off by an hour because the New_York timezone file thinks you were on New York's DST last summer and miscalculates the GMT offset. If you don't care if a file says it was created at 3pm instead of 2pm, then just copy the new timezone file over /etc/localtime. Recompile same version glibc: This is for those who have a stable system and don't want to trash it. I am not an expert at replacing a live libc, but many say it is safe if the same configure switches are used. Either way, http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/timezone/?cvsroot=glibc is the location of changes made to the timezone files. Chances are you can just replace the entire timezone directory from 2.3.(<6) with the one from 2.3.6 and it will compile and work. Other possibilities: It may be possible to just grab an already compiled timezone file from someone who has a 2.3.6 system built and just copy it over /etc/localtime. I have no idea if this will work or not. If you want to try, here is the /usr/share/zoneinfo/America/Indiana directory from a glibc-2.3.6 system: http://www.indebted2christ.com/~archaic/Indiana.tar.bz2 This is the culmination of what I learned when trying to figure out if I was affected. The information is out there for anyone who may need to know more. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
