I am filing this bug report as a more compreensive version of bug #109472. All timezone info present in "glibc-2.3.5/timezone" is out of date. The info there has been extracted from tzdata2005h.tar.gz and tzcode2005h.tar.gz. Current versions are tzdata2005n.tar.gz and tzcode2005n.tar.gz. Please update these info as each release of tzdata and tzcode present updates for several different timezones in the world. Here is a copy of a portion of the README file inside "glibc-2.3.5/timezone" that will help you updating the proper files: ------------------------------------------------------------ The files zic.c zdump.c ialloc.c scheck.c tzfile.h private.h tzselect.ksh checktab.awk come from the tzcode package by Arthur David Olson et.al. The files africa antarctica asia australasia europe northamerica southamerica pacificnew etcetera factory backward systemv solar87 solar88 solar89 iso3166.tab zone.tab leapseconds yearistype come from the tzdata package by Arthur David Olson et.al. ------------------------------------------------------------ My intention is to file a bug for each tzdata and tzcode released for now on (I'm subscribed to the tz mailing list). I don't think there should be a new glibc ebuild for each tzdata release. The tzdata releases much more often than Gentoo should release glibc's ebuilds. My intention is just to guarantee that each glibc ebuild has the must up to date timezone info available. I mean, please keep the same schedule of glibc's ebuilds. Just get the more up to date tzdata and tzcode available at the time release. This is my idea. I am not sure the toolchain mantainers are interested in these bug reports. Please advise.
*** Bug 109472 has been marked as a duplicate of this bug. ***
Created attachment 70840 [details, diff] Patch for the "glibc/timezone" directory to bring it up to date with tzdata and tzcode 2005n Here is a patch to the "glibc/timezone" directory to bring it up to date. If you are interested, I can prepare a similar patch for each tz release. This patch used glibc-2.3.5-r2 ebuild as it's starting point.
Created attachment 70850 [details, diff] Brings "glibc/timezone" up to date (changed orignal and final directories). I've only changed the original and final directories of the diff command. The real content is the same. I believe it will be easier to apply the patch the way it is now.
Comment on attachment 70850 [details, diff] Brings "glibc/timezone" up to date (changed orignal and final directories). we're going to go the route that fedora is using at the moment ... that is, we're going to break the timezone out into a sep package since it really is an external package from glibc
Great idea. Any release dates? Please let me know if I can help.
Created attachment 70894 [details] tzdata.tar.bz2 give this a try ... it'll overwrite your glibc zoneinfo files, but that's ok as long as you dont unmerge the package ;)
Created attachment 70942 [details] The tz ebuild with a few modifications. I am sending the tz ebuild with a few modifications: 1. changed name. I don't think neither tzdata nor tzcode are good names as this ebuild effectivelly installs both. I am proposing simply tz. I think tzlib is another good option. There might be other options. Please don't name it tzdata nor tzcode. 2. modified patch. The prior patch didn't install the "right" timezones. That's not glibc's behaviour. 3. modified ebuild. Included ~x86 in KEYWORDS. This version is installed in my system and it seems to be ok.
> 1. changed name. I don't think neither tzdata nor tzcode are good names as reason to go with tzdata is that is what Fedora uses > 2. modified patch. The prior patch didn't install the "right" timezones. sounds good
> reason to go with tzdata is that is what Fedora uses Well, I can't tell why Fedora named it tzdata but please don't do it in Gentoo. Either tzdata or tzcode would be misleading names.
maybe, but 'tz' is just obscure while 'libtz' doesnt apply since we dont install libtz 'timezone' or 'zoneinfo' might be ok
> maybe, but 'tz' is just obscure while 'libtz' doesnt apply since we dont install libtz I agree. > 'timezone' or 'zoneinfo' might be ok I see the point of both. I vote for 'timezone' as it seems more descriptive. What will be the relation between 'glibc' and 'timezone' ebuilds? Should 'glibc' have a PDEPEND on 'timezone'?
glibc will probably DEPEND/RDEPEND on this package
I believe glibc can't DEPEND on this package (timezone?) as it would make timezone be installed before glibc. I am not sure about the behaviour of RDEPENDs. Do they get installed after the main package? Anyway I believe they better relation would be PDEPEND. glibc doesn't depends on timezone to run (which is the meaning of RDEPEND as I far as I can understand). timezone should be installed after glibc is installed (which is the precise meaning of PDEPEND as I understand it). BTW, to minimize the chances of unexpected behaviours, I believe that there should be added a comment (or warning) at the end of glibc installation stating that after an upgrade of glibc timezone should be reemerged to guarantee that the timezone info is properlly updated. Otherwise the user would get old timezone info (the one available in glibc) until there is another timezone package. The text could be something like: "Upgrading sys-libs/glibc usually downgrades timezone info. Please (re)emerge sys-libs/timezone."
*** Bug 94088 has been marked as a duplicate of this bug. ***
*** Bug 68403 has been marked as a duplicate of this bug. ***
glibc-2.3.5-r3 and timezone-data now in portage
*** Bug 110968 has been marked as a duplicate of this bug. ***
Reminder: Summer time in 2006 Australia is incorrect, without this timezone-data. Incorrectly changes on 26 March 2006, URGENT? The change effects Melbourne, Sydney, Adelaide, Hobart and related zones. Info: http://www.lawlink.nsw.gov.au/lawlink/Corporate/ll_agdinfo.nsf/pages/community_relations_daylight_saving zdump -v /usr/share/zoneinfo/Australia/Adelaide |grep "2006" The output should contain "Sun Apr 2" not "Sun Mar 26"
wrong forum for such concerns e-mail tz@elsie.nci.nih.gov
Sorry for the confusion, the timezone data supplied by sys-libs/timezone-data-2006b (and upstream) is correct for Australia. The problem: STABLE series of gentoo's glibc does NOT install timezone-data AND does not have a correct timezone data for Australia. So unless Australians install the (currently) unstable timezone-data, their time will be wrong for a week from Sunday March 26th. I believe this matter may need urgent attention. (else end-user headaches) The timezone data for Australia has been fixed in Fedora and Ubuntu. And Windows via hotfix. :-)
