[Fedora-php-devel-list] [[e-mail]: Re: [php-maint] Bug#535770: PHP system timezone patch for 5.3?]

[Joe Orton]

Looks like I failed to CC that as intended, copying for the archives.

----- Forwarded message from Joe Orton <jorton(a)redhat.com&gt; -----

From: Joe Orton <jorton(a)redhat.com&gt;
To: sean finney <seanius(a)debian.org&gt;
Cc: PHP Packagers <pkg-php-maint(a)lists.alioth.debian.org&gt;,
	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 -----