Looks like I failed to CC that as intended, copying for the archives. ----- Forwarded message from Joe Orton <jorton@xxxxxxxxxx> ----- From: Joe Orton <jorton@xxxxxxxxxx> To: sean finney <seanius@xxxxxxxxxx> Cc: PHP Packagers <pkg-php-maint@xxxxxxxxxxxxxxxxxxxxxxx>, 535770@xxxxxxxxxxxxxxx, judas.iscariote@xxxxxxxxx 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 ----- _______________________________________________ Fedora-php-devel-list mailing list Fedora-php-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-php-devel-list
