On 03/14/2007 12:11 PM, John Lange wrote:
Just out of curiosity; is your system clock set to UTC?
No, I use local time for the RTC on all our Linux systems. Just a habit from the days when many of them dual-booted between Linux and Windows. However, I was able to tell by the timezone string that the date command put out whether the change had taken effect or not.
When the system time changed, the processes on some machines seem to have picked up the time change no problem while on other machines the processes had to be restarted or the machine rebooted.
I'm just trying to figure out why that would be the case?
Anyone have any ideas?
I imagine it would depend on whether the process had already done a localtime conversion or not. If it had done it prior to the update, it would have the old zoneinfo data cached in memory and wouldn't pick up the change without having to be restarted.
As a side question; why the heck are the timzone files in a binary format? Wouldn't life be much easier if they were just plain text?
This keeps the zoneinfo files small and very quick for the tzset() function to load and process. Plain text files would mean a bigger zoneinfo collection and a bit more time for every process to read in and "compile" the data on the first tzset(). With today's fairly bloated systems, it might not make a big difference, but when BSD first developed this scheme I'm betting it helped.
Trouble is the transition times are 32-bit integers, so the whole format will need to be scrapped or extended before 2038. Actually, the documentation ("man tzfile") says "type long", so maybe on 64-bit machines, the format will automatically extend to 64-bit if the compiler makes 64 bits the default for long ints -- it'll just mean that binary zoneinfo files will be different on 32 and 64 bit machines. However, currently the i386 and x86_64 RPMs of tzdata-2007c-1.fc6.noarch.rpm are identical "noarch" files, so I'm guessing that right now at least they're 32-bit only.