Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

DST 2007 -- problems witn RHEL AS3, AS4?



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

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org