On 04/09/07, Volker Kuhlmann <[EMAIL PROTECTED]> wrote: > > A paperweight? For just having a clock out by an hour in one timezone? Wow. > > A computer which can't show the time right is pretty bad IMHO.
This is sort of OT now, especially because *you* know all this, but for the sake of the wider readership ... There's nothing wrong with the OS clock, that runs in UT (Universal Time), and is kept correct by either sheer luck, or the NTP daemon. When a user (and this includes "server programs") asks to see what the time is, the OS will translate UT into your timezone. Each user can have their shell operating in a different timezone if they like, by just changing the TZ environment variable. If there is no TZ variable, the default is basically the contents of /etc/timezone Because NZ has recently (and with what could really be termed "insufficient notice"; and some may argue "insufficient reason" - a 42000 person petition doesn't really convince me) changed the dates on which the NZ timezone will shift into Daylight Savings mode, the extensive database that Unix machines use needs an update. http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Resource-material-Information-We-Provide-About-Daylight-Saving?OpenDocument&ExpandView "Daylight saving now runs from the last Sunday in September until the first Sunday in April." This database for most distributions of Linux and Unix is the Olsen Database, have a look at http://www.twinsun.com/tz/tz-link.htm for te sort of work these people put in to looking after time zone info. The current revision of the database itself is fine, of course. Rule NZ 2007 max - Sep lastSun 2:00s 1:00 D Rule NZ 2008 max - Apr Sun>=1 2:00s 0 S http://search.gmane.org/search.php?group=gmane.comp.time.tz&query=new+zealand > Yes of course, replacing /etc/localtime (and a few of the same under > /usr/share/zoneinfo to be safe) with the file from SUSE (or any > other distro which does publish an update) is trivial, but bypassing the > packaging system comes at the expense of the obvious drawbacks. > Hence a new package would be the better solution, but if there isn't one, > the manual fix is the right one. It sounds like a manual fix will be required, sadly. However you may enjoy editing the local rulebase and compiling it, rather than copying in data from another distro. Grab the latest tzinfo files from twinsun, extract them in a temporary location, and then use 'zic' to compile the 'australasia' file. zic will overwrite the correct system binary files with the compiled result (yes, you should be root to do so). Test with zdump -v Pacific/Auckland | grep '200[78]' Actually, test before the 'zic', and after. Enjoy. > I realise 3.1 is (obviously) no longer supported, but an upgrade to 4 is out > of the question. One has to stabilise at some point. Sure, agreed. I think the risks of compiling your own tz data files are pretty low, even in the face of a later update to libc6. -jim
