You will have to <strikethrough>bare</strikethrough> bear with me on this one as I'm not entirely sure I understand it. Based on my reading so far, when (any) Linux boots up, it takes the time from an external source (such as a CMOS/BIOS clock), applies the localtime offset to it and it passes this to the kernel so the kernel has it's own time. Also, based on what I've read, it would seem that many Linux distros (Slackware included) don't take care of updating the kernel timezone offset automatically (without reboot) when the DST kicks in.

If correct, this appears to be causing problems on one of my servers where I use a time based iptables rule. Iptables appears to be using the kernel time - and every time we change to DST, iptables is one hour out until I reboot the machine. If I check the date/time from the command line, this is correct though even before I reboot - so it looks it is just the kernel that gets stuck on the old offset until reboot.

If all the above is correct - would it be possible for Slackware to take care of updating the kernel TZ automatically when DST kicks in - so that iptables works correctly and doesn't need a server reboot every time? After all, Linux is famous for not needing reboots - and all other software on the machine seems to cope fine with the new time automatically.

I have my hardware clock set to UTC.

Then again, I could be wrong about some of the above?

Edit: OK - a bit more head scratching, and it would seem that iptables uses now UTC by default - and --kerneltz is discouraged (mainly because of the above issues). So I modified my rc.firewall to translate the times I want from local time to utc (as the desired times are always in local time) and feed them to the iptables commands, and then also set a cronjob to restart the firewall at the weekend - which should fix things automatically when there is a DST change at the weekend.

However, the kerneltz will still be stuck on the old offset until a reboot - but I guess that is not my problem any more :-)

I won't go "bare" with you, yuck. You probably meant "bear with me"?

Thanks Eric - I've edited now the original post. Any chance of an IT slanted comment

hwclock --systz ?

... but I doubt anything is going to be referencing the kernel tz structure anyway, it was obsoleted long ago, and never really worked propperly even when it wasn't.

setsystz utility https://lkml.org/lkml/2007/2/19/214

If my understanding is correct, the system TZ and the kernel TZ are separate entities. On the other hand, hwclock --hctosys sets both of them, according to the man page.