Weekly Edition
Return to the Press page
| |||||||||||||
Switching your Linux systems to the new DST (Linux-Watch)
Linux-Watch looks at the
change in US Daylight Savings time. ""Spring forward; Fall
back," That's the way the saying goes. Some years I get it backwards, but I
eventually catch on. I've never had to worry about my PCs getting it wrong
before, though. Now, with the recent changes in the Daylight Savings Time
(DST) rules, I do. Fortunately, there are ways to make sure that both my
Linux computers and I get the new rules right."
(Log in to post comments)
Distro Notes Posted Mar 7, 2007 1:07 UTC (Wed) by ldo (subscriber, #40946) [Link] SuSE 10.0 and later already have the updated rules for US DST. There is an update RPM available (timezone-2.3.4-23.9) for 9.3, which is the oldest non-yet-obsolete version.
How to Check Posted Mar 7, 2007 1:11 UTC (Wed) by ldo (subscriber, #40946) [Link] Given that the change is less than a week away, try a couple of commands like the following: TZ=US/Pacific date If your zoneinfo is up to date, the time of day shown by the second command should be an hour later than from the first one. Folks actually in the US can leave off the "TZ=..." part.
How to Check Posted Mar 7, 2007 6:14 UTC (Wed) by tzafrir (subscriber, #11501) [Link] zdump -v /etc/localtime | grep 2007
Dimdows Posted Mar 7, 2007 1:42 UTC (Wed) by ldo (subscriber, #40946) [Link] One thing that surprises me is that, for Microsoft Windows, you don't just need an update patch for the OS, you need patches for applications like Outlook as well. In *nix/Linux systems as far as I'm aware, all the apps just use the common zoneinfo data, so you only need one update for that to fix all your apps. Why doesn't Windows do the same?
Dimdows Posted Mar 7, 2007 4:40 UTC (Wed) by jwb (guest, #15467) [Link] I don't know why, but Microsoft and the calendar have never gotten along well. Their application for fast-track standardization of the Office XML format was stalled because it requires implementations to give incorrect dates in the year 1900. Of course, the Gregorian calendar has been around for only 250 years or so, and is only used by every nation on Earth, so it's not quite as powerful as Microsoft ;)
Dimdows Posted Mar 7, 2007 5:37 UTC (Wed) by rahvin (subscriber, #16953) [Link] Of course, the Gregorian calendar has been around for only 250 years or so, and is only used by every nation on Earth, so it's not quite as powerful as Microsoft ;)Although acknowledged and accommodated by those nations engaging in trade with the US and western Europe, it's hardly used in a significant number of countries outside the trade environment. In fact China actively uses a 5000+ year calender, and most Muslim countries use a calender based on the birth of Mohammad and Islam. In fact the Gregorian calender probably has the lowest numbers of population actively using it than almost any of the other calenders.
Dimdows Posted Mar 7, 2007 5:56 UTC (Wed) by k8to (subscriber, #15413) [Link] Do these other countries actually reckon things like Month and Day of Year with totally different numbers, or do they just use a different year offset? Yeah I guess I should do some reasearch, but your post leaves it unclear.
(off to do some google searches)
Dimdows Posted Mar 7, 2007 6:06 UTC (Wed) by k8to (subscriber, #15413) [Link] Cursory searching says most countries (eg. including china) do use the Gregorian calendar day to day, although some continue to use a totally incompatable calendar, notably the Islamic calendar.
Lunar years, what a crazy concept. How about sidereal years? Jovian years? These countries will probably give up their Islamic calendar over time, because it's just a pain in the butt.
Gradual adoption of the Gregorian calendar Posted Mar 7, 2007 9:32 UTC (Wed) by xoddam (subscriber, #2322) [Link] While several regions and religions (eg. China, Vietnam, Judaism, Islam and various flavours of Christianity) do indeed have a traditional or religious lunar calendar in active use, these are invariably used alongside the Gregorian calendar that was first adopted by the Roman Catholic Church in 1582. The only countries I'm aware of whose *official* calendar is not more-or-less the standard Gregorian one are Ethiopia (which has not changed the calendar it uses for two milennia and still has a leap day every four years without fail), Israel and most Islamic countries (though note that Iran and Afghanistan maintain an official Persian solar calendar for civil purposes which is neither Islamic nor Gregorian). Japan numbers its years from the start of the present Emperor's reign, and the Republic of China counted (and still counts in Taiwan) from its foundation in 1912.
The official adoption of the Gregorian calendar has been gradual -- most countries with Roman Catholic governments converted within a few months of the church itself, while Protestant and Orthodox countries held out for centuries (probably leading to the claim above that the calendar has "been around for 250 years or so"). Denmark and the Protestant parts of Germany switched calendars in 1700, Britain and its possessions in 1752, Russia in 1918, Serbia in 1919, and Greece in 1923.
Many parts of the world had the Gregorian calendar thrust upon them by European colonisers and generally retained it after independence (Israel is the exception which proves the rule, switching from Gregorian to the Jewish lunar calendar on its foundation). Other non-European countries adopted the Western calendar, either for convenience or for the sake of modernity, well after it was in established commercial use -- Japan (more or less) in 1873, China in 1912, Turkey in 1917 (with double-dating until 1926).
All documents are double-dated in Israel. The Islamic countries which use the religious calendar for official purposes necessarily maintain some solar calendar in addition, usually based on the Gregorian one except in Iran and Afghanistan.
> In fact the Gregorian calender probably has the lowest numbers of
That statement is pretty absurd. The only places the Gregorian calendar (or some variant, like counting years differently) isn't used for everyday life are Ethiopia and a few of the most strictly Islamic countries -- and even Iran uses its own solar calendar alongside the Islamic lunar one.
The various lunar calendars are at best difficult, and at times downright impossible, to use for forward planning and international commerce, even with neighbouring countries ostensibly using the same system. The Islamic religious calendar relies on visual observation of each new moon, so it is different depending on longitude, and can't be used to refer accurately to dates even one month in the future as the leap days are unpredictable. Conventional approximations exist, but are not appropriate for religious observance and until a few years ago were inconsistent even between neighbouring Muslim countries. The obvious fallback is the same calendar used for commerce with secular neigbours -- even Iran has those. There is no part of the world that doesn't use the global standard calendar for some purpose.
Dimdows Posted Mar 7, 2007 9:04 UTC (Wed) by fandom (subscriber, #4028) [Link] If it makes you feel better, they only did it to be compatible with aLotus bug:
http://www.joelonsoftware.com/items/2006/06/16.html
like they say, software is like sex, one mistake and you have
Dimdows Posted Mar 7, 2007 16:30 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] Microsoft products tend to do their internal calculations and storage formats in local time. This simplifies display, as there isn't any knowledge of time zone required. That was fine when DOS asked you the current time and date every time you booted, and was *somewhat* liveable after the advent of CMOS clocks. The OS just needed to know what DST algorithm to apply. Of course, it can make or some whacky date stamp issues for files created around DST switches--there are some time stamps that are truly ambiguous. It also gets weird when you have users from multiple time zones on the same machine.
UNIX and its derivatives tend to do those same things in GMT. This eliminates much of the clock twiddling mess and so on. Also, file date stamps are never ambiguous. What changes is time display. That needs a notion of the current time zone. The plus side is that you can have two dozen users logged in, each in different time zones, and each can see their own local time, just by setting TZ.
So if you don't patch Windows, it'll *use* the wrong time. If you don't patch UNIX, it'll just *display* the wrong time. (Although, some programs that operate in terms of localtime on UNIX, such as cron, will use that wrong time.)
Java doesn't use zoneinfo Posted Mar 8, 2007 2:48 UTC (Thu) by bcd (subscriber, #11759) [Link] Not quite true... Java does not use zoneinfo, it uses its own internal database instead. See http://java.sun.com/developer/technicalArticles/Intl/USDST/ for more information. They are providing a tool to patch existing installations if a full upgrade isn't possible.
Java doesn't use zoneinfo Posted Mar 8, 2007 15:22 UTC (Thu) by nix (subscriber, #2304) [Link] PostgreSQL, Python and Perl also have their own private copies of the Olson database.
not using zoneinfo Posted Mar 8, 2007 23:50 UTC (Thu) by ldo (subscriber, #40946) [Link] Don't you think that's stupid? What's the excuse of these people for not using zoneinfo and the standard C run-time API calls for accessing it? For instance, I look at Perl and Python, and I can see no timezone functionality that they offer beyond what's available through the standard C run-time.
not using zoneinfo Posted Mar 10, 2007 1:36 UTC (Sat) by nix (subscriber, #2304) [Link] They do use the standard C runtime API calls: but if you want to ask whatthe time is in something other than the current locale, or if you want to make any query of the timezone database other than `what time is it now' (perhaps `when does the time change next' or `will the time jump in the next day') then POSIX provides no interfaces that will help (and neither does glibc, nor will it ever, apparently).
So in that situation you must either locate and directly access the system
not using zoneinfo Posted Mar 11, 2007 1:36 UTC (Sun) by ldo (subscriber, #40946) [Link] All the things you mentioned can be determined from the standard zoneinfo database. I could probably even calculate them all just by using the standard POSIX API calls. Repeat after me: "Always use zoneinfo! Never try to roll-your-own!"
Blame POSIX Posted Mar 11, 2007 10:53 UTC (Sun) by kleptog (subscriber, #1183) [Link] PostgreSQL does use the zoneinfo database, they just modified the code to make it more usable. Until recently the zoneinfo database was 100% compatable so you could symlink them with the version supplied by the OS. (Upstream added support for leap-seconds, which changed the disk format). The reasons why PostgreSQL uses its own are:
1. Access to multiple timezones. The only way to do that in POSIX is to set the TZ environment variable. Which means that if you run a query using two timezones, the C library would reload the timezone file twice for every row in your query. Say goodbye to performance.
2. Cross-platform support. Not every OS uses zoneinfo (*cough*Windows*cough*), so if you want consistant query results across 11 OSes, you need to manage it yourself.
3. Stability. Not every C library was memory-leak free when faced with hundreds of timezone changes per second.
If the writers of POSIX had simply from the beginning decided to allow the timezone as an argument to the time functions, this would be much less of an issue. Recently I looked at glib, figuring it might handle this. But no, it also assumes your whole program only wants to work in one timezone. Ugh.
I made a plugin to Gaim to display the times of other users. I also copied the zoneinfo code into that, because it's a big no-no for plugins to start playing with environment variables, especialy those with such a wide effect as TZ... Yes, Glibc can do it, but there's always the *but it doesn't work on Windows* crew...
not using zoneinfo Posted Mar 9, 2007 2:35 UTC (Fri) by ldo (subscriber, #40946) [Link] Somehow I didn't think the people behind Python and Perl were that stupid, so I went back to check. On a SuSE 9.3 system I just updated a few days ago with the latest timezone RPM, both Python and Perl do correctly show local times across the upcoming daylight-saving transition in the US time zones. Checking the contents of that RPM, it contains a few updated utility binaries, plus of course a new version of the zoneinfo database. No Python- or Perl-specific (or other language-specific) updates at all.
not using zoneinfo Posted Mar 10, 2007 1:31 UTC (Sat) by nix (subscriber, #2304) [Link] Python, oops, I misspoke (no Python sources nearby when I posted that andI was going from fallible memory).
As for Perl, the DateTime::TimeZone module on CPAN incorporates a copy of
Re: Java doesn't use zoneinfo Posted Mar 9, 2007 2:38 UTC (Fri) by ldo (subscriber, #40946) [Link] I find that a shock, given that Sun hold one of the major concentrations of Unix mojo going back decades. Why on Earth would they do things in such a brain-damaged way?
Re: Java doesn't use zoneinfo Posted Mar 9, 2007 6:52 UTC (Fri) by njs (guest, #40338) [Link] For the same reason that Java specifies the exact size of its integer types (unlike C) and makes it a fatal compiler error to have an potentially uninitialized variable -- the goal was to make the behavior predictable in *every* case, no matter the underlying hardware, OS, etc.
Incomplete Procedures Posted Mar 7, 2007 13:04 UTC (Wed) by mikeraz (guest, #155) [Link] In addition to what the author describes one must also update /etc/localtime.
/usr/share/zoneinfo/localtime is a softlink to /etc/localtime - untouched by his procedure. The system will still rely on information in /etc/localtime.
Incomplete Procedures Posted Mar 7, 2007 13:59 UTC (Wed) by Los__D (guest, #15263) [Link] It is also like that on my Ubuntu Edgy system (so probably also on other Debian systems), but I seem to remember it being opposite on the Linux systems I've used before that?
On Gentoo, I think I linked /etc/localtime to my timezone manually, as part of the install.
On my company's FreeBSD system, /etc/localtime is a copy of the original.
Incomplete Procedures Posted Mar 7, 2007 17:17 UTC (Wed) by zlynx (subscriber, #2285) [Link] Whenever I have a choice I make /etc/localtime a symlink to the real zone file. The only case where I think /etc/localtime as a standalone file is reasonable is when you need localtime before mounting /usr. And how often does that come up?
Incomplete Procedures Posted Mar 7, 2007 21:46 UTC (Wed) by jimmybgood (guest, #26142) [Link] When I mount a file system I like to run sanity checks on the superblock information as well as check to see if enough time has passed to require a file system check. Both of these require knowledge of the local time.
So my /etc/localtime is a copy of the zoneinfo not a symlink. BTW, this is how Debian and Fedora do it.
Incomplete Procedures Posted Mar 7, 2007 22:39 UTC (Wed) by njs (guest, #40338) [Link] What are these sanity checks that require localtime? Surely your superblock, if it stores times, should be storing them in UTC?
And "check[ing] to see if enough time has passed" doesn't seem like it would need localtime either, it's actually easier to calculate time deltas using UTC than localtime?
Curiously yours,
|
|||||||||||||