Thanks to the local state government's recent decision to give daylight savings another chance despite it being knocked back the last three times the issue was brought up, IT staff all around Perth have been scrambling around trying to get their systems ready for it. Now, I don't really care if we have daylight savings or not. That's not what I object to. No, what I do object to is the meagre two weeks of notice that the government gave everybody. That sort of rash decision making has created quite a few problems, which is why I think they decided on the three year trial - so everyone would forget about the problems with its introduction.

So anyway, we're here and we're stuck with it. How do you make your systems Western Daylight Stupid time aware? If you're in Windows land, you can download the patch that'll fix you in about 75% of cases (except for your Outlook appointments - they'll be out by an hour). Mac users can probably just tick a box, but if you're in Linux land you've got a few more problems, mainly revolving around the fact that most vendors won't release new timezone files in a two week turnaround, let alone giving enough time for Sys Admins to perform proper testing. With a bit of digging around, you can figure out how to make your systems WDST aware.

First there's the simple way. Simply set your "TZ" environment variable with the appropriate POSIX compliant TZ string. Eg:

You can verify the string using the "tzselect" command. This approach is simple and easy, but is limited to only processes that inherit this environment. Its useful in a situation where you're working on a remote system that's in a different timezone and you want it to appear as if it was in your own timezone, but not so useful for a system wide change. One of the deficiencies is that its not really timezone aware for any other period. Ideally, you want to display times from different DST ranges in their correct timezone, but if they have different ranges, or only run certain years, then you can see that this approach is not suitable.

The other solution is to provide a system tzfile for the timezone. This is what your system uses to set the timezone for the entire system. /etc/localtime is often a symlink to the tzfile for the appropriate timezone (eg: /usr/share/zoneinfo/Australia/Perth). By writing your own file and linking to it (or simply setting it using the TZ environment variable) you can resolve some the issues above.

These files are actually binary files compiled from definition files contributed to by interested individuals. You can download the definitions and the code to compile them from the web. A script to do it all for you might look like this:

You can then just poach the files you're after from the tzdir directory and copy them into to appropriate locations on your local filesystem (ensuring to backup the originals first). If you want to create your own zonefile, you can do so by creating your own definition file and using the "zic" tool to compile it. You can inspect the contents of any of these binary files using the "zdump" command.

Funnily enough, the definition file for Australia/Perth has already been updated (although not yet propagated to your installer package), so you shouldn't need to roll your own. Just copy the new ones in, verify them, and you're almost done. The last thing to remember is that processes that have already looked up the timezone information will need to be restarted, as the relevant libraries will cache the information to save time later. It might be simpler to reboot your machine, but you can stop and restart all the important daemons that you're interested in (don't forget "cron"!)