Slashdot Mirror

when you are dealing with multi-year timespans where a second or two one way or the other can make a significant difference -- mainly astronomy, celestial mechanics, and satellite stuff.

Last time I had to deal with leap seconds in software, I found this: Sources for Time Zone and Daylight Saving Time Data which describes a system level time information database that includes leap seconds as well as Daylight Savings Time and time zones.

There are leap-second-aware time functions available that can be rolled into GNU C. Once they are in place, adding a leap second is a trivial sysadmin operation to update the time-info-database. Then all software using it will be correct without need to re-build or recompile.

So, for all of those who dislike DST, try this: Just get up an hour later.

I don't really care how time is reckoned so long as there is some agreement about it, but I object to being told that I am saving daylight when my reason tells me that I am doing nothing of the kind. I even object to the implication that I am wasting something valuable if I stay in bed after the sun has risen. As an admirer of moonlight I resent the bossy insistence of those who want to reduce my time for enjoying it. At the back of the Daylight Saving scheme I detect the bony, blue-fingered hand of Puritanism, eager to push people into bed earlier, and get them up earlier, to make them healthy, wealthy and wise in spite of themselves.

I'm uncertain as to what you mean by "this feature"? Showing incorrect historical file timestamps?

As for "dynamic timezones", most *nix distributions use timezone files which have historical information. Check out zoneinfo for more information, as well as a list of *nix distributions which use it. *nix distributions have had this feature for, oh, about 20 years.

From a programmers perspective, time zone stuff is pretty easy to work around.

See here for the latest TZ data: http://www.twinsun.com/tz/tz-link.htm

The command to compile & install is "zic"
Have fun! (I know I am... :/ )

The tz database http://www.twinsun.com/tz/tz-link.htm underlies time zone handling for the GNU C Library, FreeBSD, NetBSD, OpenBSD, Mac OS X, Solaris and many more, and is kept current by a dedicated team of (mostly?) volunteers. For time nerds, the historical comments in the plain text files of the tz ftp distribution (ftp://elsie.nci.nih.gov/pub/tzdata2007b.tar.gz) are required reading.

If you're a Firefox person, FoxClocks (see my URL above) puts nice little world clocks on your statusbar. And yes, it uses tz too. Thanks guys. Andy

More general info on Wikipedia: http://en.wikipedia.org/wiki/Zoneinfo
zoneinfo homepage: http://www.twinsun.com/tz/tz-link.htm

The file formats haven't changed so no software needs recompiled.
You just need new data files. If you can't get an RPM, you can just
compile the zone files yourself. Do a man on the zic command.

POSIX is also based on UTC

"Daylight savings time is an idiotic solution to a non-existent problem."

And while every other aspect of the gregorian calendar can be described in just a few lines of code, the daylight-savings time requires a 450KB database just to find out which timezone you're in, with entries like "during the second world war, London experimented with double daylight-savings time..." (admittedly most of that 450K is comments)

1. UNIX/Linux/MacOS X:
   • The good news: Apps that use the zoneinfo files will work correctly--provided the Sysadmin updates them. The latest source is available from http://www.twinsun.com/tz/tz-link.htm (click on the FTP distribution link. The source files must then be compiled using the zic (zone information compiler) utility.
   • The bad news: If the app's not using the zoneinfo files (perhaps because the user's TZ environment variable is set to a POSIX time zone rule literal,) then all bets are off. POSIX TZ rule literals are evil.
2. Windows: The current time zone rules are stored in the Windows Registry. Changing them requires either a Windows Update, or else using Regedit and doing it by hand. Unlike Unix, the Windows time zone definitions only represent the curret annual transition ruleset--past history is not supported. This means that Windows timestamps captured in the past will show local time based on the new rules (once they're updated,) regardless of the actual local time at the (Universal) point-in-time designated by the timestamp. The analogous situation holds for future points-in-time.
3. Java: Analgogous situation to that of Windows (see above,) only worse due to the following serious design flaw in the standard Sun date/time classes: "Dates" are reprsented as to-the-millisecond timestamps that designate midnight of the intended date in a particular time zone. Now, what happens to the "date" when local time is reintrepted as being one hour earlier?