Bug 173091 - [RHL,FC1,FC2, FC3] glibc, tzdata -- Timezone data needing updating
[RHL,FC1,FC2, FC3] glibc, tzdata -- Timezone data needing updating
Status: CLOSED ERRATA
Product: Fedora Legacy
Classification: Retired
Component: glibc (Show other bugs)
unspecified
All Linux
medium Severity low
: ---
: ---
Assigned To: Fedora Legacy Bugs
http://www.redhat.com/archives/fedora...
LEGACY
: Reopened
: 180582 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-13 19:39 EST by David Eisenstein
Modified: 2007-04-18 13:34 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-20 04:14:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File /usr/share/zoneinfo/America/New_York (1.24 KB, application/octet-stream)
2006-10-17 21:56 EDT, Rob Cluett
no flags Details
FC5's version of /usr/share/zoneinfo/America/New_York (1.24 KB, application/octet-stream)
2006-10-20 04:05 EDT, David Eisenstein
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 152848 None None None Never
Red Hat Bugzilla 167743 None None None Never

  None (edit)
Description David Eisenstein 2005-11-13 19:39:34 EST
Description of problem:
Due to legislative changes in the U.S. and other areas of the world, timezone
information will need to be updated.

Version-Release number of selected components to be updated:

RHL7.3 - glibc-2.2.5-44.legacy.6.src.rpm
RHL9   - glibc-2.3.2-27.9.7.2.legacy.src.rpm
FC1    - tzdata-2004b-1.fc1.src.rpm
FC2    - tzdata-2005f-1.fc2.src.rpm

Additional info:
This was originally discussed in bug 152848, a glibc security bug.
Comment 1 Pekka Savola 2005-11-16 08:18:37 EST
This doesn't seem to be important enough to fix just on its own, so mark it DEFER.
Comment 2 Bradley 2006-01-05 20:58:35 EST
Australia has changed DST for this year, extending it by one week (end of March
to start of April) due to the commonwealth games. So an update before the end of
March would be nice :)
Comment 3 Danny Yee 2006-01-26 23:41:46 EST
I concur, an update before March would be good.  Does anyone have a quick
explanation of how to fix my RH7.3 and FC1 machines if there's no update before
then?
Comment 4 Marc Deslauriers 2006-02-11 13:35:19 EST
From bug 180582:

Description of problem:   
   
Because of the Commonwealth Games here in Melbourne this year the various   
Australian states that do Daylight Savings Time have put back the end of DST to   
April 2nd for 2006 (was March 26th).   
   
However, this is not reflected in the glibc-common in RH7.3 yet.   
   
$ zdump -v /usr/share/zoneinfo/Australia/Melbourne | grep 2006   
/usr/share/zoneinfo/Australia/Melbourne  Sat Mar 25 15:59:59 2006 UTC = Sun Mar   
26 02:59:59 2006 EST isdst=1 gmtoff=39600   
/usr/share/zoneinfo/Australia/Melbourne  Sat Mar 25 16:00:00 2006 UTC = Sun Mar   
26 02:00:00 2006 EST isdst=0 gmtoff=36000   
/usr/share/zoneinfo/Australia/Melbourne  Sat Oct 28 15:59:59 2006 UTC = Sun Oct   
29 01:59:59 2006 EST isdst=0 gmtoff=36000   
/usr/share/zoneinfo/Australia/Melbourne  Sat Oct 28 16:00:00 2006 UTC = Sun Oct   
29 03:00:00 2006 EST isdst=1 gmtoff=39600   
   
A corrected TZ file from FC4 shows that it should be:   
   
$ zdump -v /tmp/Melbourne | grep 2006   
/tmp/Melbourne  Sat Apr  1 15:59:59 2006 UTC = Sun Apr  2 02:59:59 2006 EST   
isdst=1 gmtoff=39600   
/tmp/Melbourne  Sat Apr  1 16:00:00 2006 UTC = Sun Apr  2 02:00:00 2006 EST   
isdst=0 gmtoff=36000   
/tmp/Melbourne  Sat Oct 28 15:59:59 2006 UTC = Sun Oct 29 01:59:59 2006 EST   
isdst=0 gmtoff=36000   
/tmp/Melbourne  Sat Oct 28 16:00:00 2006 UTC = Sun Oct 29 03:00:00 2006 EST   
isdst=1 gmtoff=39600   
   
   
Version-Release number of selected component (if applicable):   
   
glibc-common-2.2.5-44.legacy.6   
   
How reproducible:   
   
Always   
   
Steps to Reproduce:   
1.  zdump -v /usr/share/zoneinfo/Australia/Melbourne | grep 2006   
2.   
3.   
     
Actual results:   
   
/usr/share/zoneinfo/Australia/Melbourne  Sat Mar 25 15:59:59 2006 UTC = Sun Mar   
26 02:59:59 2006 EST isdst=1 gmtoff=39600   
/usr/share/zoneinfo/Australia/Melbourne  Sat Mar 25 16:00:00 2006 UTC = Sun Mar   
26 02:00:00 2006 EST isdst=0 gmtoff=36000   
/usr/share/zoneinfo/Australia/Melbourne  Sat Oct 28 15:59:59 2006 UTC = Sun Oct   
29 01:59:59 2006 EST isdst=0 gmtoff=36000   
/usr/share/zoneinfo/Australia/Melbourne  Sat Oct 28 16:00:00 2006 UTC = Sun Oct   
29 03:00:00 2006 EST isdst=1 gmtoff=39600   
   
   
Expected results:   
   
/usr/share/zoneinfo/Australia/Melbourne  Sat Apr  1 15:59:59 2006 UTC = Sun Apr    
2 02:59:59 2006 EST isdst=1 gmtoff=39600   
/usr/share/zoneinfo/Australia/Melbourne  Sat Apr  1 16:00:00 2006 UTC = Sun Apr    
2 02:00:00 2006 EST isdst=0 gmtoff=36000   
/usr/share/zoneinfo/Australia/Melbourne  Sat Oct 28 15:59:59 2006 UTC = Sun Oct   
29 01:59:59 2006 EST isdst=0 gmtoff=36000   
/usr/share/zoneinfo/Australia/Melbourne  Sat Oct 28 16:00:00 2006 UTC = Sun Oct   
29 03:00:00 2006 EST isdst=1 gmtoff=39600   
   
Additional info:   
  
Already fixed in RHEL3 (bugzilla #167743), RHEL4, FC3 & FC4 and SuSE SLES9
Comment 5 Marc Deslauriers 2006-02-11 13:36:16 EST
*** Bug 180582 has been marked as a duplicate of this bug. ***
Comment 6 Chris Samuel 2006-02-11 18:12:03 EST
As the person who filed the duplicate (sorry, no idea why this bug didn't 
appear in the search for "Australia" I did in legacy) I'd also like to ask if 
there is an estimated time for a fix and whether there is anything I can do to 
help to get this fix out ?  
  
I suspect, as a work around, you could copy 
the /usr/share/zoneinfo/Australia/Melbourne file (or your appropriate city) 
from an FC3 box over the one onto earlier, unfixed systems, as the tzdump on 
RH7.3 at least reads them fine. 
 
Alternatively, if you didn't want to overwrite the old one you might be able 
to copy it in as $CITY-2006 and set your TZ to be that instead of just 
Melbourne. 
 
NB: Both those work arounds are completely untested! 
Comment 7 Marc Deslauriers 2006-02-11 20:33:31 EST
I will be creating packages for this in the next few days. If you'd like to
help, you can test the packages I'll make to see if they seem to fix the issue
for you.
Comment 8 Chris Samuel 2006-02-12 17:22:17 EST
(In reply to comment #7) 
> I will be creating packages for this in the next few days. If you'd like to 
> help, you can test the packages I'll make to see if they seem to fix the 
> issue for you. 
 
Not a problem, happy to help.  Fortunately we run a large cluster that's stuck 
back on 7.3 for software support reasons so I can isolate a node in that for 
this test. 
 
Chris 
Comment 9 Marc Deslauriers 2006-02-18 19:40:04 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are updated packages to QA:

rh7.3:
25f40ce35680c6f0221234045e698dbb7a91ecdc  7.3/glibc-2.2.5-44.legacy.7.i386.rpm
fbbc043c6dd6954a1053b3f506b42cb8ae98d83d  7.3/glibc-2.2.5-44.legacy.7.i686.rpm
fe865eb1786d26db613a248275ceabffb2c39095  7.3/glibc-2.2.5-44.legacy.7.src.rpm
e6620f62a9c921f24ce48844b86673928cab5797 
7.3/glibc-common-2.2.5-44.legacy.7.i386.rpm
696cb79ca1722adbad3c2488f2d0563b4c5b16a5  7.3/glibc-debug-2.2.5-44.legacy.7.i386.rpm
2342709113e5c67d7a016d0b0783fade953a7c60  7.3/glibc-debug-2.2.5-44.legacy.7.i686.rpm
fef960d6bd66d7f8821201e88965be3c6929cd85 
7.3/glibc-debug-static-2.2.5-44.legacy.7.i386.rpm
a3e26c04d9f6b08423cff79fc94068fd5498f783  7.3/glibc-devel-2.2.5-44.legacy.7.i386.rpm
6a7cf6153e8aac4ec703173179cdf4ee08ebf405 
7.3/glibc-profile-2.2.5-44.legacy.7.i386.rpm
9015af6bf17c6b912ed0e3ae15af06ba5961203e  7.3/glibc-utils-2.2.5-44.legacy.7.i386.rpm

Source:
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-2.2.5-44.legacy.7.src.rpm

Binaries:
http://www.infostrategique.com/linuxrpms/legacy/7.3/

rh9:
d20741b698d6d40485a17b81f97575587e3dd677  9/glibc-2.3.2-27.9.7.3.legacy.i386.rpm
4bc7a3c7968c351677b225f620e1660312f9eeb6  9/glibc-2.3.2-27.9.7.3.legacy.i686.rpm
d678ce06caaa2f80f54d04436e803a0e6e7ec1f4  9/glibc-2.3.2-27.9.7.3.legacy.src.rpm
1bdddc103b8a224a00e097e59ee2e670b75a252a 
9/glibc-common-2.3.2-27.9.7.3.legacy.i386.rpm
fa2ac2be90bb38682761ad6cfe9427a7453ffae0 
9/glibc-debug-2.3.2-27.9.7.3.legacy.i386.rpm
34246b6434920bc3bf19cdc397202972ae4504bc 
9/glibc-devel-2.3.2-27.9.7.3.legacy.i386.rpm
9afb306188f950efea02d9cc24ad84524411abed 
9/glibc-profile-2.3.2-27.9.7.3.legacy.i386.rpm
3ddf7117ffb35e106041bf7f0eb28316d52fa94e 
9/glibc-utils-2.3.2-27.9.7.3.legacy.i386.rpm

Source:
http://www.infostrategique.com/linuxrpms/legacy/9/glibc-2.3.2-27.9.7.3.legacy.src.rpm

Binaries:
http://www.infostrategique.com/linuxrpms/legacy/9/

fc1:
7cc7c53dc8d21b27393b174b33895817ab88a341  1/tzdata-2005r-3.fc1.1.legacy.noarch.rpm
a4a73d1b1fe2a061bc95868efe6fc8a0ca41f2e1  1/tzdata-2005r-3.fc1.1.legacy.src.rpm

http://www.infostrategique.com/linuxrpms/legacy/1/tzdata-2005r-3.fc1.1.legacy.noarch.rpm
http://www.infostrategique.com/linuxrpms/legacy/1/tzdata-2005r-3.fc1.1.legacy.src.rpm

fc2:
68ac000da45d43876e9d184099a5098ad02c4301  2/tzdata-2005r-3.fc2.1.legacy.noarch.rpm
5cc1354d2f4a7194e922e0c15bb428917ff253be  2/tzdata-2005r-3.fc2.1.legacy.src.rpm

http://www.infostrategique.com/linuxrpms/legacy/2/tzdata-2005r-3.fc2.1.legacy.noarch.rpm
http://www.infostrategique.com/linuxrpms/legacy/2/tzdata-2005r-3.fc2.1.legacy.src.rpm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFD97/cLMAs/0C4zNoRAifrAKC/c5cFRYMoGnAAD+SHO5ohnnzRoACgt/jQ
NORBN3sru2ExSbDKFNrQe2c=
=yXwK
-----END PGP SIGNATURE-----
Comment 10 Pekka Savola 2006-02-19 03:06:17 EST
tzdata packages look good, but the base used in glibc-2.3.6 is based on
tzdata-2005m.  tzdata-2005r has since then been imported in the glibc cvs and is
available in the snapshots.  Do we want to have different timezone data across
glibc versions?
Comment 11 Marc Deslauriers 2006-02-19 08:52:54 EST
Actually, the snapshots contain tzdata-2006a. I could remake the packages with
2006a, but we'd still have different timezone data across releases.

Then again, we could go for 2006a for the glibc releases, as they are harder to
update and release tzdata packages for 2006a when they come out for FC4+...

What do you think, Pekka?
Comment 12 Pekka Savola 2006-02-19 11:05:25 EST
I don't have a firm opinion either way.  I don't think the changes between 2005m
and 2006a are probably major, but then again, I don't think FL needs to update
the timezone information in any case unless there's a really major change
somewhere..

For easing the QA and making it easier to make updates in the future, I'd
however suggest (if that seems reasonable and would work -- haven't tested it
myself) that  instead of a patch we'd just reuse our FC's timezone data which
could be extracted under the glibc's timezone/ directory, overwriting the old
files.  That way we could use 2005m as well.

Do you think that would work?  Is just untarring tzcode and tzdata equivalent to
the patch you used?
Comment 13 Marc Deslauriers 2006-02-19 13:00:00 EST
Not quite. There are a couple of minor differences between the source files in
tzcode/tzdata and the source files in glibc. The makefile is completely
different, so it would have to be hacked on. I think it would be a lot easier to
use a glibc snapshot that to try and merge the changes ourselves.

I think one of the major changes added in 2006a is some parts of Indiana
changing timezones soon. Then again, RHEL is still at 2005m for the moment...
Comment 14 Marc Deslauriers 2006-02-19 13:01:05 EST
What I could do, is find a glibc snapshot that has 2005r, that way we'll be at
2005r across the board. What do you think?
Comment 15 Pekka Savola 2006-02-19 13:15:57 EST
Either using 2006a (if that contains some updates that would be useful in any
case) or finding a 2005r snapshot works for me...
Comment 16 David Eisenstein 2006-02-19 23:32:28 EST
I am confused on which distros (if any) are ready for publish QA'ing and which
are not, so I am marking the whiteboard "NEEDSWORK" for now.

Let me know if you would like some help rolling new packages once it is sorted
out, or if I can help in any other way.

Regarding which timezone data to use, I am happy with 2005r, if the users with
the most problems are happy with that set of timezone data, especially our
Australian contingent.

I haven't researched the differences between 2005r and 2006a myself, so I am
happy either way.  I don't know what's with Indiana though.  If we have
Indiana users who will scream fairly soon if something breaks on their
systems, maybe we can do it 2006a across the board, if it makes sense to do
so.  If we decide 2006a is the way to go and it means extra work, I'll be
glad to roll up my sleeves and help if you need it, Marc.  Just let me know.

In other words, I'm flexible, but my opinion isn't worth much as I'm not in
any of the the zones affected.  :-)
Comment 17 David Eisenstein 2006-02-19 23:39:30 EST
Oh - another wrinkle.  If we update timezone data, do we need to consider
updatine the tzdata packages in FC3 as well?
Comment 18 Pekka Savola 2006-02-20 00:35:22 EST
Fedora Project upgraded FC3 to 2005r before stopping maintenance, so for now, no
work is needed for FC3.
Comment 19 Robert Reynolds 2006-02-20 09:05:49 EST
We are from Indiana and have decided that many vendors are too slow to pick up
the necessry changes in tzdata and glibc.  We are running RHEL AS 3 and AS 2.1.

To fix the problem we are switching /etc/localtime from
/usr/share/zoneinfo/America/Indianapolis to /usr/share/zoneinfo/US/Eastern and
changing the ZONE in /etc/sysconfig/clock to US/Eastern.

This will make some of our historical files display a timestamp an hour later
than they should but that is better than waiting until the last minute for a
vendor fix that may not come.

Given production change schedules, we cannot wait any longer.  Best wishes as
you scramble to help Indiana customers of RedHat who have not anticipated this
statewide change well enough.

By the way, Mac OS X has already patched this and delivered the fix to its users.
Comment 20 Petr Machata 2006-02-22 12:26:43 EST
The most significant change between 2005r and 2006a was for Indiana. Most of the
Indiana will introduce DST, few counties will also change their zone. This is
quite a major change, I'd vote for pushing 2006a.
This shouldn't be a problem for fedoras, as I think all of them have tzdata as
separate package. Older RHs probably ship tzdata via glibc, so that is more
difficult issue... any help I can provide?
Comment 21 Marc Deslauriers 2006-02-23 19:32:41 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are updated packages for rh73 and rh9 to QA:
They incorporate timezone data version 2006a from the recent
glibc snapshot.

rh7.3:
13710bb66258d834f2b698e477d19117d6041b3f  glibc-2.2.5-44.legacy.8.i386.rpm
5c01da316f163528bffe2dfa561b2376be3b9896  glibc-2.2.5-44.legacy.8.i686.rpm
9bd785bb1620274842f893278c0b2bb79e5cc0ca  glibc-2.2.5-44.legacy.8.src.rpm
bc031c2d7d60977073be382b446019099e42a870  glibc-common-2.2.5-44.legacy.8.i386.rpm
57183750b1e16a6d678a7ce81a4c4e52f850a27c  glibc-debug-2.2.5-44.legacy.8.i386.rpm
5c04dba6b6e6ea2293397582b6d4142bcb369424  glibc-debug-2.2.5-44.legacy.8.i686.rpm
6a1bb7f7e5dabdd0fd2c1ed90352ed7cd63fc3bc 
glibc-debug-static-2.2.5-44.legacy.8.i386.rpm
3140b0a4224da9257b5a790939f1b279c6a7ec46  glibc-devel-2.2.5-44.legacy.8.i386.rpm
2b6452729bb064a9a3a72cc2e7c68670624d3790  glibc-profile-2.2.5-44.legacy.8.i386.rpm
80a154d44cca0d85d0506b2b2572606aade51f87  glibc-utils-2.2.5-44.legacy.8.i386.rpm
ab189629932ee71a25846fa3d5df498c9f87d306  nscd-2.2.5-44.legacy.8.i386.rpm

Source:
http://www.infostrategique.com/linuxrpms/legacy/7.3/glibc-2.2.5-44.legacy.8.src.rpm

Binaries:
http://www.infostrategique.com/linuxrpms/legacy/7.3/

rh9:
3ca7c3b03297def648da946b5dcfb9d889a1c00b  glibc-2.3.2-27.9.7.4.legacy.i386.rpm
28fc0510ded71af2ec19dcaba605c2de9bb31111  glibc-2.3.2-27.9.7.4.legacy.i686.rpm
b02e1607ac9a8c6d6ef8d73ec72202dacb7750c2  glibc-2.3.2-27.9.7.4.legacy.src.rpm
4f0b20d421462808dca9ea060f117d007e2ceb3b 
glibc-common-2.3.2-27.9.7.4.legacy.i386.rpm
9c83f6bfde74fd3331c17ece47f5df9ff5ef615d  glibc-debug-2.3.2-27.9.7.4.legacy.i386.rpm
4b4cfda78b72723155eda102889afa4be9e7be24  glibc-devel-2.3.2-27.9.7.4.legacy.i386.rpm
01e7c16e45d2cede77e701937137bab8ae811a74 
glibc-profile-2.3.2-27.9.7.4.legacy.i386.rpm
d8408702a3f41365ba1b1e66134d9f158c8f6210  glibc-utils-2.3.2-27.9.7.4.legacy.i386.rpm
c00ce0c37833504d332c1347bc9196a59a085911  nscd-2.3.2-27.9.7.4.legacy.i386.rpm
74bedc43fdaa12512a1e9572b96609b2f4b53747  nptl-devel-2.3.2-27.9.7.4.legacy.i686.rpm

Source:
http://www.infostrategique.com/linuxrpms/legacy/9/glibc-2.3.2-27.9.7.4.legacy.src.rpm

Binaries:
http://www.infostrategique.com/linuxrpms/legacy/9/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFD/lUILMAs/0C4zNoRAhPJAJ41F2ZJHH69jEzFwOCS7eOgsW7TMQCdEjg0
lhtRBJYUg3hBPQ4EJ1wt7wQ=
=977B
-----END PGP SIGNATURE-----
Comment 22 Pekka Savola 2006-02-24 01:36:21 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
QA w/ rpm-build-compare.sh:
 - source integrity good
 - spec file changes minimal, FC backports looked sane
 - RHL patches verified by diffing glibc snapshot's timezone/ to the
   originals
 
+PUBLISH RHL73, RHL9, FC1, FC2
 
9bd785bb1620274842f893278c0b2bb79e5cc0ca  glibc-2.2.5-44.legacy.8.src.rpm
b02e1607ac9a8c6d6ef8d73ec72202dacb7750c2  glibc-2.3.2-27.9.7.4.legacy.src.rpm
a4a73d1b1fe2a061bc95868efe6fc8a0ca41f2e1  tzdata-2005r-3.fc1.1.legacy.src.rpm
5cc1354d2f4a7194e922e0c15bb428917ff253be  tzdata-2005r-3.fc2.1.legacy.src.rpm
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
 
iD8DBQFD/qqHGHbTkzxSL7QRAjKYAJwNUFGGxHat4qqIXUnz4vozjYfG/ACfcP4b
ZeZTwqUmUy7mWePcq8xiFvc=
=9Ukq
-----END PGP SIGNATURE-----
Comment 23 David Eisenstein 2006-02-28 09:49:45 EST
Just in case anyone is interested, I have built 2006a-based tzdata packages
for Fedora Core 1.  I've installed them on my FC1 machine, and it hasn't
started smoking yet!  :^)

Built the package based on the devel tree in CVS, tag "tzdata-2006a-2".

Source package:
ebce830d475513202d17e1877cd652731b987108  tzdata-2006a-2.fc1.1.src.rpm

Noarch binary package:
7b621b3da5f80223681becfc40bc6166fbc75d10  tzdata-2006a-2.fc1.1.noarch.rpm

Downloadable at:   http://fedoralegacy.org/contrib/tzdata/

Hope this is helpful.     -David
Comment 24 David Eisenstein 2006-02-28 09:52:17 EST
Petr, I've noticed there are 2006b trees out in CVS already.  Do you know
whether or not RHEL is planning to go with them or with 2006a?  How about
FC4 and FC5?
Comment 25 Petr Machata 2006-03-01 05:56:29 EST
The changes between 2006a and 2006b were only in package organization -- no data
were actually updated.  I think the release isn't necessary, as the update
brings nothing new to users. I think I will release 2006a for fedoras, and will
leave 2006b for rawhide for a while.
Comment 26 Marc Deslauriers 2006-03-01 20:14:42 EST
Packages were pushed to updates-testing.
Comment 27 Pekka Savola 2006-03-02 03:00:38 EST
Timeout in 2 week.s
Comment 28 Tom Yates 2006-03-02 11:05:32 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

18a13ba104fd958e1abcbe42cdf2ae31c9b0cb30 glibc-2.3.2-27.9.7.4.legacy.i686.rpm
cb5501a39b03cacda052757f8265bc6f02c92883 glibc-common-2.3.2-27.9.7.4.legacy.i386.rpm
753ea0d554610c4dd35cc54764def86269c2c148 glibc-devel-2.3.2-27.9.7.4.legacy.i386.rpm
112788df6619fb9fc39282ab0eeaf7718d34f8b5 glibc-utils-2.3.2-27.9.7.4.legacy.i386.rpm

install OK, system doesn't instantly grind to a halt (as i would expect a
broken libc to do)(*).  zdump output reflects what comment #4 leads me to
expect from the fix.

+VERIFY RH9

(*) phew!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEBxinePtvKV31zw4RAtsbAJ98/EZdjYDmI+y60dSOY9XsmoulDwCcDY4F
y4m/17VyJlDQ3PHNUsKfJC4=
=nmv5
-----END PGP SIGNATURE-----
Comment 29 Pekka Savola 2006-03-02 14:33:50 EST
Thanks!
Comment 30 Chris Samuel 2006-03-06 21:49:34 EST
Just back from Japan - anything need doing for RH 7.3 that I can assist with ? 
Comment 31 Marc Deslauriers 2006-03-06 22:39:22 EST
You could test the rh73 packages that are now in updates-testing to see if
everything's ok and report back here.
Comment 32 Jim Popovitch 2006-03-07 08:14:29 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

VERIFY++ RH73

Tested and verified on production systems (web/mail) and a handful of prep/test
machines.  Works fin
e with no noticeable errors.

4e4fce10ff1cfbdda21dbd0ca19132ffa3b34a15  glibc-2.2.5-44.legacy.8.i686.rpm
ccc856a5f596cffca0d76f124ffff2df7cecd413  glibc-common-2.2.5-44.legacy.8.i386.rpm


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQFEDYhpMyG7U7lo69MRAuYMAKCpKqAV7w/p3Z7qdwFf2b6VOR0N1gCfThV0
ddvjlwptVPgWBgeITpyKJrg=
=cULY
-----END PGP SIGNATURE-----
Comment 33 Pekka Savola 2006-03-07 08:23:58 EST
Thanks!

Timeout shortened by one week.
Comment 34 Pekka Savola 2006-03-09 00:26:52 EST
Timeout over.
Comment 35 David Eisenstein 2006-03-21 13:24:50 EST
I notice these haven't been released to updates yet.  Wondering why...

If someone wants, I can submit the FC1 2006a package (in comment #23) for
source QA and make and submit a similar FC2 2006a for source QA too ...
either here or in another bug report.

Do you want me to write up an update advisory, Marc?

Where are we on this bug?
Comment 36 Marc Deslauriers 2006-03-21 17:50:20 EST
I was under the impression an updated tzdata package was coming out for FC4 "any
day now". I was putting off releasing these hoping to be able to release 2006a
packages. We could release 2006a for FC1 and FC2, but we may break the upgrade
path. Well, we may go ahead and release 2006a packages.

David, would you submit some, I'll QA them and put them in updates-testing.
Comment 37 Bradley 2006-03-21 18:11:49 EST
The Australian change is from this Sunday morning Australia time - ie 3.5 days
away. I don't think that theres time for another qa cycle....

I went and rolled out the prerelease RH7.3 update last week, because I couldn't
wait any longer. A few hundred machines, and haven't seen any problems from it.
Comment 38 David Eisenstein 2006-03-21 19:17:17 EST
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are tzdata 2006a source packages for FC1, FC2, and FC3, for source QA.

8cf5a5f68002b9e79f444803df85dd044bcc7cce  tzdata-2006a-2.fc1.1.src.rpm
b20178ce22885b073bb1c07e096dc1ed81ca6c6e  tzdata-2006a-2.fc2.1.src.rpm
7362fea2d0c6a3288d3fbb3f9245e19efed3e745  tzdata-2006a-2.fc3.1.src.rpm

http://turbosphere.fedoralegacy.org/logs/fedora-1-core/11-tzdata-2006a-2.fc1.1/tzdata-2006a-2.fc1.1.src.rpm
http://turbosphere.fedoralegacy.org/logs/fedora-2-core/21-tzdata-2006a-2.fc2.1/tzdata-2006a-2.fc2.1.src.rpm
http://turbosphere.fedoralegacy.org/logs/fedora-3-core/31-tzdata-2006a-2.fc3.1/tzdata-2006a-2.fc3.1.src.rpm

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFEIJcrxou1V/j9XZwRAsA6AKD8nqKC3nKxgarhQ5pK3c0e2SjDXACgxRbO
qdbA60HXp1nJN39A67AW/YA=
=FXdA
-----END PGP SIGNATURE-----
Comment 39 Chris Samuel 2006-03-21 19:39:52 EST
(In reply to comment #37) 
 
> I went and rolled out the prerelease RH7.3 update last week, because I 
> couldn't wait any longer. A few hundred machines, and haven't seen any 
> problems from it. 
 
I think I'm going to have to do the same. :-( 
Comment 40 Petr Machata 2006-03-22 04:29:47 EST
2006b was pushed for update in FC4.
However, Australian change was in 2005m, according to changelog. The changes
that made 2006a interesting were for Indiana/US, and they are effective Apr/2 2006.
Comment 41 Bradley 2006-03-22 06:30:02 EST
Yeah, but the 2005m ones havne't been pushed to legacy yet ;)

(BTW, can the announcement mention the requirement to run system-config-date a
bit more noticable? Else people will install the package and not actuall have it
take effect ;)
Comment 42 David Eisenstein 2006-03-22 11:06:04 EST
FYI- 2006a pkgs. were released in RHEL 3 & 4, so these can be used as a
basis for comparison for PUBLISH QA votes here.  See Red Hat Enhancement
Advisory:  <http://rhn.redhat.com/errata/RHEA-2006-0213.html>; RHEL .src.rpms
are here:

<http://mirrors.kernel.org/redhat/redhat/linux/updates/enterprise/3AS/en/os/SRPMS/tzdata-2006a-1.EL3.src.rpm>
<http://mirrors.kernel.org/redhat/redhat/linux/updates/enterprise/4AS/en/os/SRPMS/tzdata-2006a-1.EL4.src.rpm>.

FWIW, the only packages that are being held up are the Fedora Core ones.  The
RHL 7.3 & RHL 9 packages are ready to be released as far as I know, and they
include the 2006a timezone data.  Those packages currently in updates-
testing for RHL 7.3 & RHL 9 will be the very same packages that you download
from updates, when they get pushed from updates-testing.  So, Bradley, you
should be good to go (from comment #37).  And Chris, if you use RHL, you also
should be good to go (from comment #39).

I believe we're expediting the QA process for this, as there's not much to
break.  The FC timezone packages are noarch packages and only contain data,
so there are no library dependencies that can break.
Comment 43 Marc Deslauriers 2006-03-23 00:08:20 EST
I have QA'd and VERIFY'd David's packages and have released them to updates.
Comment 44 Rob Cluett 2006-07-25 10:15:26 EDT
This did not work for Redhat v9.  After installing of the rpm's the date still 
does not reflect Extended Daylight Savings in the US for 2007.
Comment 45 Rob Cluett 2006-07-25 10:15:52 EDT
This did not work for Redhat v9.  After installing of the rpm's the date still 
does not reflect Extended Daylight Savings in the US for 2007.
Comment 46 Marc Deslauriers 2006-07-25 19:54:05 EDT
Did you re-set your timezone using the system-config-date utility?
Comment 47 Rob Cluett 2006-07-25 23:07:05 EDT
I have not.  I was unable to run it from my telnet session.  I don't believe 
it's installed on this Redhat server:

[root@enssbos /]# find -name system-config-date
Comment 48 Rob Cluett 2006-07-25 23:07:33 EDT
I have not.  I was unable to run it from my telnet session.  I don't believe 
it's installed on this Redhat server:

[root@enssbos /]# find -name system-config-date(In reply to comment #46)
> Did you re-set your timezone using the system-config-date utility?

Comment 49 Rob Cluett 2006-07-25 23:21:20 EDT
It's redhat-config-date.  I have that on my system.  I'll give it a go now.
Comment 50 Rob Cluett 2006-07-26 09:57:24 EDT
Still no luck... here was the install and the test.

[root@enssbos gd-1.8.4]# rpm -Ufh /usr/local/src/glibc-2.3.2-27.9.7.4.legacy.i3
86.rpm /usr/local/src/glibc-2.3.2-27.9.7.4.legacy.i686.rpm /usr/local/src/glibc
-common-2.3.2-27.9.7.4.legacy.i386.rpm /usr/local/src/glibc-debug-2.3.2-27.9.7.
4.legacy.i386.rpm /usr/local/src/glibc-profile-2.3.2-27.9.7.4.legacy.i386.rpm /
usr/local/src/glibc-utils-2.3.2-27.9.7.4.legacy.i386.rpm /usr/local/src/nptl-de
vel-2.3.2-27.9.7.4.legacy.i686.rpm /usr/local/src/nscd-2.3.2-27.9.7.4.legacy.i3
86.rpm /usr/local/src/gd-1.8.4-11.1.legacy.i386.rpm /usr/local/src/gd-devel-1.8
.4-11.1.legacy.i386.rpm /usr/local/src/gd-progs-1.8.4-11.1.legacy.i386.rpm
warning: /usr/local/src/glibc-2.3.2-27.9.7.4.legacy.i386.rpm: V3 DSA signature:
NOKEY, key ID 731002fa
warning: package glibc = 2.3.2-27.9.7.4.legacy was already added, replacing with
 glibc <= 2.3.2-27.9.7.4.legacy
########################################### [100%]
        package glibc-profile-2.3.2-27.9.7.4.legacy is already installed
        package nptl-devel-2.3.2-27.9.7.4.legacy is already installed
        package nscd-2.3.2-27.9.7.4.legacy is already installed
[root@enssbos gd-1.8.4]# redhat-config-date &
[1] 17804
[1]+  Done                    redhat-config-date
[root@enssbos gd-1.8.4]# date
Mon Mar 26 09:44:36 EST 2007
[root@enssbos gd-1.8.4]#
Comment 51 Marc Deslauriers 2006-07-26 16:36:15 EDT
What timezone are you set to? What results are you expecting the date command to
return?
Comment 52 Rob Cluett 2006-07-27 09:17:47 EDT
Hi Marc, thanks for the quick response.  I am set to New York.  Typically 
Daylight Saving Time would occur on the first Sunday of April and end on the 
last Sunday of October.  

Due the Energy Policy Act we will be moving the clocks ahead to the second 
Sunday in Mach and moving them back on the first Sunday of November.  So, for 
2007 it will occur on March 11th at 2:00am and end on November 4th at 2:00am.  

Here is my test:

Sat Jul 22 16:40:00 EDT 2006			
Sat Mar 10 16:41:00 EST 2007	date 031016412007	pass	
Sat Mar 31 16:41:00 EST 2007	date 033116412007	fail	After Mar 11th 
at 2:00am should be in EDT
Sun Apr  1 16:41:00 EDT 2007	date 040116412007	pass	
Sat Oct 27 16:41:00 EDT 2007	date 102716412007	pass	
Sun Oct 28 16:41:00 EST 2007	date 102816412007	fail	Oct 28th Should 
still be in EDT
Sat Nov  3 16:41:00 EST 2007	date 110316412007	fail	Nov 3rd Should 
still be in EDT
Sun Nov  4 16:41:00 EST 2007	date 110416412007	pass	

- Rob Cluett
Comment 53 Rob Cluett 2006-07-27 09:20:09 EDT
I wanted to clarify, this is not just effecting 2007 but will be a change for 
each year going forward, I used 2007 as my test since it is the first year it 
will be in effect.
Comment 54 Rob Cluett 2006-08-03 08:58:32 EDT
Hello all.  Sorry if I'm a bother but I was hoping someone might be able to 
offer some advice.  I'm hopeful that maybe I installed it incorrectly but I'm 
leaning more towards the idea that the Extended DST for US 2007 was not added.  
No idea really.  Does anyone have any insight and thanks to all who responded 
thus far.
Comment 55 Rob Cluett 2006-09-22 10:39:21 EDT
Can this bug be re-opened please?
Comment 56 David Eisenstein 2006-09-23 07:07:31 EDT
Okay.  Reopened.  This may affect RHL 7.3 and FC3 as well.

My guess is that the tzdata in recent versions of RHEL 2.1 and 3 will have
been updated.

Sorry about our slowness, Rob.  We're pretty drastically understaffed at the
moment, and a lot of things have not been being addressed very well lately.
Comment 57 Rob Cluett 2006-09-25 06:50:38 EDT
Thanks David, I appreciate your help here with all this!  I'll continue to 
check back.   Thanks again! - Rob
Comment 58 Rob Cluett 2006-09-25 19:55:33 EDT
I noticed that my glibc-2.3.2-200304020432-timezone.patch file in the SOURCE 
directory contains what looks like the entry for the 2007 US DST.  See below:

# Rule	NAME	FROM	TO	TYPE	IN	ON	AT	SAVE	LETTER/S
Rule	US	1918	1919	-	Mar	lastSun	2:00	1:00	D
Rule	US	1918	1919	-	Oct	lastSun	2:00	0	S
Rule	US	1942	only	-	Feb	9	2:00	1:00	W # War
Rule	US	1945	only	-	Aug	14	23:00u	1:00	P # 
Peace
Rule	US	1945	only	-	Sep	30	2:00	0	S
Rule	US	1967	2006	-	Oct	lastSun	2:00	0	S
Rule	US	1967	1973	-	Apr	lastSun	2:00	1:00	D
Rule	US	1974	only	-	Jan	6	2:00	1:00	D
Rule	US	1975	only	-	Feb	23	2:00	1:00	D
Rule	US	1976	1986	-	Apr	lastSun	2:00	1:00	D
Rule	US	1987	2006	-	Apr	Sun>=1	2:00	1:00	D
Rule	US	2007	max	-	Mar	Sun>=8	2:00	1:00	D
Rule	US	2007	max	-	Nov	Sun>=1	2:00	0	S

Is it possible that this is part of the patch however it is not working on my 
servers?
Comment 59 Rob Cluett 2006-10-16 16:59:23 EDT
Should I expect any progress to be made on this prior to the end of this year?  
Unfortunately I have a deadline of Jan 1 to have this resolved.  I'd rather not 
install another operating system if this can and will be fixed.  Has any 
attention been paid to the U.S. issue expressed above.  Your help is of course 
appreciated.
Comment 60 David Eisenstein 2006-10-16 22:21:49 EDT
Regarding comment #58, this is puzzling.  A few questions for you, Rob.
I, too, see that patch 

  1)  Did you build your own binary packages?
  2)  Can you attach the contents of your /etc/sysconfig/clock file?
  3)  When you do '. /etc/sysconfig/clock' in a bash shell, would you
      attach the contents of file "/usr/share/zoneinfo/$ZONE" to this
      bug report?  (That is, if ZONE = "America/New_York", would you
      attach the file /usr/share/zoneinfo/America/New_York as an at-
      tachment to this bug ticket?)

Thanks.
Comment 61 Rob Cluett 2006-10-17 21:53:32 EDT
Thanks for the repsonse.  I hope these answer your questions:

1) I performed the install as expressed in the directions.  Here is what I did 
below.

[root@enssbos gd-1.8.4]# rpm -Ufh /usr/local/src/glibc-2.3.2-27.9.7.4.legacy.i3
86.rpm /usr/local/src/glibc-2.3.2-27.9.7.4.legacy.i686.rpm /usr/local/src/glibc
-common-2.3.2-27.9.7.4.legacy.i386.rpm /usr/local/src/glibc-debug-2.3.2-27.9.7.
4.legacy.i386.rpm /usr/local/src/glibc-profile-2.3.2-27.9.7.4.legacy.i386.rpm /
usr/local/src/glibc-utils-2.3.2-27.9.7.4.legacy.i386.rpm /usr/local/src/nptl-de
vel-2.3.2-27.9.7.4.legacy.i686.rpm /usr/local/src/nscd-2.3.2-27.9.7.4.legacy.i3
86.rpm /usr/local/src/gd-1.8.4-11.1.legacy.i386.rpm /usr/local/src/gd-devel-1.8
.4-11.1.legacy.i386.rpm /usr/local/src/gd-progs-1.8.4-11.1.legacy.i386.rpm
warning: /usr/local/src/glibc-2.3.2-27.9.7.4.legacy.i386.rpm: V3 DSA signature:
NOKEY, key ID 731002fa
warning: package glibc = 2.3.2-27.9.7.4.legacy was already added, replacing with
 glibc <= 2.3.2-27.9.7.4.legacy
########################################### [100%]
        package glibc-profile-2.3.2-27.9.7.4.legacy is already installed
        package nptl-devel-2.3.2-27.9.7.4.legacy is already installed
        package nscd-2.3.2-27.9.7.4.legacy is already installed
[root@enssbos gd-1.8.4]# redhat-config-date &
[1] 17804
[1]+  Done                    redhat-config-date
[root@enssbos gd-1.8.4]# date
Mon Mar 26 09:44:36 EST 2007
[root@enssbos gd-1.8.4]#


2)  

[root@enssbos /]# more /etc/sysconfig/clock
ZONE="America/New_York"
UTC=true
ARC=false

3) See attached...

Comment 62 Rob Cluett 2006-10-17 21:56:24 EDT
Created attachment 138739 [details]
File /usr/share/zoneinfo/America/New_York

As requested.
Comment 63 David Eisenstein 2006-10-20 04:05:06 EDT
Created attachment 138947 [details]
FC5's version of /usr/share/zoneinfo/America/New_York

$ ls -lrt *New_York | colrm 1 28
1267 Aug 19  2005 RH9-glibc-common-2.3.2-27.9.7.2.legacy.i386-New_York
1267 Feb 22  2006 RH9-glibc-common-2.3.2-27.9.7.4.legacy.i386-New_York
1267 Aug 10 08:42 Centos4.4-New_York
1267 Oct 16 20:08 FC5-New_York
1267 Oct 20 00:16 Rob_Cluett's-New_York

$ sha1sum *New_York
6c180234a50db8eb42b5ecb7606af2aef824640a__RH9-glibc-common-2.3.2-27.9.7.2.legacy.i386-New_York

8dbc9bc069b3b386c1782c21187b0937063a9b57__RH9-glibc-common-2.3.2-27.9.7.4.legacy.i386-New_York

8dbc9bc069b3b386c1782c21187b0937063a9b57__Centos4.4-New_York
8dbc9bc069b3b386c1782c21187b0937063a9b57__FC5-New_York
6c180234a50db8eb42b5ecb7606af2aef824640a__Rob_Cluett's-New_York


   -------
Rob, apparently you do not have installed on your computer the latest
version of the '/usr/share/zoneinfo/America/New_York' file, which is
available in the most recently released glibc-common rpm package that
is available in Fedora Legacy's repositories.  The most recently re-
leased one is glibc-common-2.3.2-27.9.7.4.legacy.i386.rpm.  

I do not know why.

The above screenshot demonstrates that /usr/share/zoneinfo/America/New_York
in the 'glibc-common.2.3.2-27.9.7.4.legacy.i386.rpm' package is the same
New_York file as is packaged in Centos 4.4 and in Fedora Core 5.  I found
on my Fedora Core 5 system that using its New_York file (with the sha1sum
of 8dbc9bc069b3b386c1782c21187b0937063a9b57) yields the expected results
for Daylight Savings time at least in March of 2007.  Didn't test October.

It appears that the New_York file on your Red Hat Linux 9 computer is the
same as one packaged in 'glibc-common.2.3.2-27.9.7.2.legacy.i386.rpm' or
earlier package.  That fact makes me wonder if the package got properly
installed on your machine.

You may wish to verify that the 'glibc-common' package that you have in-
stalled on your Red Hat Linux 9 computer is 
'glibc-common.2.3.2-27.9.7.4.legacy.i386'.  You should be able to verify
that by issuing:
	       $ rpm -qf /usr/share/zoneinfo/America/New_York
command.

I don't think we can help you any more than this, at least in the context
of a Bugzilla ticket.  The New_York file provided by the most recent
'glibc-common' package for Red Hat Linux 9 is the correct file, and properly
installed on a RHL9 system, should yield the correct time zones for March
2007 and beyond.  There is no bug in the packages that Legagcy is providing
in the repositories.

If you wish to do a workaround, I am attaching a copy of my FC5 New_York
file, which you can just copy into /usr/share/zoneinfo/America/ directory
on your RHL 9 computer.

Hope this helped.
Comment 64 David Eisenstein 2006-10-20 04:14:45 EDT
For further help, please subscribe and post to the fedora-legacy-list
mailing list:
  <https://www.redhat.com/mailman/listinfo/fedora-legacy-list>.

Thanks.  Closing bug ticket.

Note You need to log in before you can comment on or make changes to this bug.