Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
I checked minerva and olduvai. Minerva, running CentOS 4.4, correctly handles this for /bin/date and perl strftime. Olduvai, running Fedora Core 2, fails on both. I upgraded tzdata on olduvai, to tzdata-2006p-1, but /bin/date still fails to switch to EDT on March 11. In the end, I just copied /etc/localtime from minerva to olduvai, and that seems to have fixed both /bin/date and perl. Kind of an ugly hack, but I guess it will do until I get around to rebuilding olduvai. On 1/23/07, Bill Ricker <bill.n1vux at gmail.com> wrote: > General advice has been that if the OS is patched for the DST change, > Perl (and most everything else) will be OK between March 11 and Apr 4, > when US DST starts 3 weeks early this year. > > However, Red Hat Enterprise Linux 3's Perl 5.8.0 doesn't notice that > the DST date for the OS changed when the OS was patched for this. > (ZDUMP confirms that the OS believes dates roll at new time 3/11.) I > grabbed a "dst.pl" test script from HP Support's forums and it's > working fine everywhere else, but appears to report "unpatched" on the > RHEL3 system that is patched according to ZDUMP(8) and release levels. > > I wondered if this was perhaps GCC 2 => GCC 3 transition legacy > baggage, but I've convinced myself that the Perl is GCC323 same as the > OS. > > [Links on http://use.perl.org/~n1vux/journal/32234 & > http://www.perlmonks.com/?node_id=596027] > > Just to be paranoid, I tried explicitly printing > strftime( localtime( 1173596400 )); /* 1 sec after 3-11-01:59:59ET */ > with either C or Perl gives me good answers everywhere (that I've > tried) except Red Hat Enterprise Linux release 3. The difference > between RH patches for EL2.1 and EL3.x is they were distributing LIBC > patches for EL2.1 but only Olson File for /usr/share/lib/zoneinfo [or > wherever] for EL3.x. > > Seems to me *anything* using LIBC's localtime() or other POSIX LOCALE > TZ data (typically anything sensitive to $ENV{TZ}) is going to have a > problem with RHEL3 and RHEL4 which updated the zoneinfo but not the > localedata/locales/en_US on the DST patch !? > > According to Red Hat KB, only need to do one of these - > # Red Hat Enterprise Linux 2.1 users must update glibc > # Red Hat Enterprise Linux 3 and 4 must update the tzdata package. > http://kbase.redhat.com/faq/FAQ_80_7909.shtm > > But there *are* apparently TWO TZ DB's on RHEL3, one in TZ and one in > LOCALE, since localtime (using $TZ) doesn't notice Olson having > updated. All separately updateable TZ DB's need updating for _all_ > software not just OS date rollover to work. > > If tzdata isn't updating glibc's locale files, there's my problem. > > [And if you have Java or Perl's DataTime::TimeZone or RogueWave > libraries, you have yet more ...] > > Comment? > > -- > Bill > n1vux at arrl.net bill.n1vux at gmail.com > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://lists.blu.org/mailman/listinfo/discuss > -- John Abreau / Executive Director, Boston Linux & Unix GnuPG KeyID: 0xD5C7B5D9 / Email: abreauj at gmail.com GnuPG FP: 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |