[php-maint] Bug#535770: PHP system timezone patch for 5.3?

[Joe Orton]

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