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 |
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.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |