Looks like I failed to CC that as intended, copying for the archives.
----- Forwarded message from Joe Orton jorton@redhat.com -----
From: Joe Orton jorton@redhat.com To: sean finney seanius@debian.org Cc: PHP Packagers pkg-php-maint@lists.alioth.debian.org, 535770@bugs.debian.org, judas.iscariote@gmail.com Date: Tue, 7 Jul 2009 10:10:06 +0100 Subject: Re: [php-maint] Bug#535770: PHP system timezone patch for 5.3? User-Agent: Mutt/1.5.18 (2008-05-17)
Hi Sean - adding the Fedora PHP devel list to CC. Thanks for getting in touch. For Fedora folks, Sean has referenced this Debian bug report:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535770
Quoting in full:
On Tue, Jul 07, 2009 at 12:05:31AM +0200, sean finney wrote:
...and hi again :)
On Mon, Jul 06, 2009 at 10:51:40PM +0200, sean finney wrote:
specifically timezone_identifiers_list() was extended to include country codes as a filter for the returned values and it doesn't look like this is covered by the patch and results in a segfault.
looking a bit more at the specifics, it doesn't seem so desirable to have to mmap and read every file to get all the country codes. here's some options i see:
read all the files anyway. performance will be dismal but it's hopefully a corner case except for someone running a public world clock app or something :)
fall back to the internal timezonedb for listing country names. it would be a bit ugly and there's maybe a possibility that timezone names might get out of sync.
pre-cache the tzdata at install time (and make use of triggers to catch updates to the tzdata files). nice performance but adds extra complexity/dependencies outside of the engine.
use zone.tab for country code -> tzdata mapping? it seems to have the info we'd want all in one file (assuming it's correct and consistant), and we'd only have to read it in the specific cases that it was needed.
disable the api extension. not desirable.
i guess zone.tab seems a nice easy and boring fix for this, what do you think?
It looks like they are (as threatened) shipping a mutated version of the zoneinfo data in 5.3. Changes:
1) first four bytes are "PHP1" not "TZif" 2) in the "reserved" 16 bytes which follow, they have: ONE BYTE: "BC" flag TWO BYTES: country code ... those are being used by the code you mention above 3) after the end of the data, they have: TWO BYTES: latitude and longtitude ONE BYTE: length N (N) BYTES: "comment"
Whereas we have the 64-bit TZif2 block at the end of the TZif data. I think that's everything that's different.
The "BC" flag seems to be an indication that the zone name is a deprecated form, and it's the case that BC is 0 if and only if the country code is '??', otherwise BC is 1; with 'UTC' as a special-case (BC=1, code is '??').
I believe it is also the case that, other than UTC, there is a one-to-one mapping between zones *not* listed in zone.tab, and zones which PHP designates with country code '??' (and hence BC=0).
zone.tab also has the lat/long data, and the country codes, so, yup, parsing that at startup seems to be the way to go. I'll have a crack at a patch later today hopefully.
Regards, Joe
----- End forwarded message -----
php-devel@lists.fedoraproject.org