Looks like I failed to CC that as intended, copying for the archives.
----- Forwarded message from Joe Orton <jorton(a)redhat.com> -----
From: Joe Orton <jorton(a)redhat.com>
To: sean finney <seanius(a)debian.org>
Cc: PHP Packagers <pkg-php-maint(a)lists.alioth.debian.org>,
535770(a)bugs.debian.org, judas.iscariote(a)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 -----