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.
This doesn't seem to be important enough to fix just on its own, so mark it DEFER.
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 :)
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?
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
*** Bug 180582 has been marked as a duplicate of this bug. ***
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!
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.
(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
-----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-----
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?
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?
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?
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...
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?
Either using 2006a (if that contains some updates that would be useful in any case) or finding a 2005r snapshot works for me...
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. :-)
Oh - another wrinkle. If we update timezone data, do we need to consider updatine the tzdata packages in FC3 as well?
Fedora Project upgraded FC3 to 2005r before stopping maintenance, so for now, no work is needed for FC3.
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.
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?
-----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-----
-----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-----
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
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?
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.
Packages were pushed to updates-testing.
Timeout in 2 week.s
-----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-----
Thanks!
Just back from Japan - anything need doing for RH 7.3 that I can assist with ?
You could test the rh73 packages that are now in updates-testing to see if everything's ok and report back here.
-----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-----
Thanks! Timeout shortened by one week.
Timeout over.
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?
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.
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.
-----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-----
(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. :-(
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.
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 ;)
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.
I have QA'd and VERIFY'd David's packages and have released them to updates.
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.
Did you re-set your timezone using the system-config-date utility?
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
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?
It's redhat-config-date. I have that on my system. I'll give it a go now.
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]#
What timezone are you set to? What results are you expecting the date command to return?
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
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.
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.
Can this bug be re-opened please?
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.
Thanks David, I appreciate your help here with all this! I'll continue to check back. Thanks again! - Rob
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?
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.
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.
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...
Created attachment 138739 [details] File /usr/share/zoneinfo/America/New_York As requested.
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.
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.