On Tue, September 4, 2007 9:25 pm, Jim Cheetham wrote: > 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
The other thing thats worth knowing is that it doesn't matter whether your hardware clock is set to UTC or local time. The hardware clock is only used on boot, and saved to on shutdown. While the computer is running the time is taken from the kernel (which may be augmented by ntp). the kernel keeps time in UTC, and (as Jim says) is translated to any arbitrary timezone by your system settings). So the procedure is: A. A system variable tells you what timezone the hardware clock is kept in (UTC or localtime). B. On boot the hardware clock is read and (if necessary, depending on the value of the variable) converted to UTC to feed to the kernel. C. The kernel chunters along in UTC, augmented by NTP until shutdown. D. On shutdown the kernel time is (if necessary) converted to whatever timezone is stored in the hardware clock and saved there for use on the next boot. Unix systems traditionally set the hardware clock to UTC, but (some, maybe not all) windows systems expect the hardware clock to be in localtime, so if you are dual booting, setting the hardware clock to localtime is the safest. If you have a *nix only system either will be fine, so long as you don't chop & change, and as long as the system knows which choice you made. -- Nick Rout
