[php-maint] Timezone querying

[Ondřej Surý]

> On Wed, Mar 17, 2010 at 10:00:59PM +0100, Ondřej Surý wrote:
>> 1. Added overhead when timezone is not set -> I don't think we should
>> really do anything in here. It's a simple matter of adding
>> date_default_timezone_set("xxx/yyy") to your application. After adding
>> this call PHP will use that value as first in guess_timezone().
>> However we could put something about it to README.Debian.
>
> What if we set the default ini configured timezone to "System/Localtime"?
> Does that remove the guessing logic or just invoke the default guessing
> pattern?

Nope, default guessing logic is still there, partially because of
check for regular file in timelib_timezone_id_is_valid:

                return stat(fname, &st) == 0 && S_ISREG(st.st_mode);

But even if I copy /etc/localtime to /usr/share/zoneinfo/ and use just
"localtime" as a name, it prints garbage:

# php -r 'var_dump(date_default_timezone_get());'
string(9) "localtime"

Because there is no undelying logic to read a zoneinfo file - it
checks just for a name of the file.

The questions is - does it matter? It looks like it really doesn't (at
least for the functions I have checked):

root at howl:/usr/share/zoneinfo# cp Europe/Prague localtime
root at howl:/usr/share/zoneinfo# php -r 'var_dump(date("r"));'
string(31) "Thu, 18 Mar 2010 11:29:00 +0100"

root at howl:/usr/share/zoneinfo# cp America/Chicago localtime
root at howl:/usr/share/zoneinfo# php -r 'var_dump(date("r"));'
string(31) "Thu, 18 Mar 2010 05:29:06 -0500"

root at howl:/usr/share/zoneinfo# cp America/Mexico_City localtime
root at howl:/usr/share/zoneinfo# php -r 'var_dump(date("r"));'
string(31) "Thu, 18 Mar 2010 04:29:13 -0600"

root at howl:/usr/share/zoneinfo# cp Europe/Lisbon localtime
root at howl:/usr/share/zoneinfo# php -r 'var_dump(date("r"));'
string(31) "Thu, 18 Mar 2010 10:29:49 +0000"

root at howl:/usr/share/zoneinfo# cp Europe/Dublin localtime
root at howl:/usr/share/zoneinfo# php -r 'var_dump(date("r"));'
string(31) "Thu, 18 Mar 2010 10:29:55 +0000"

>> 2. We call stat() everytime timelib_timezone_id_is_valid() is called.
>> That is adds some slowdown, but I don't really see a way how to fix
>> that unless you readahead all timezones, which will make PHP even more
>> slower (mainly at startup, but that happens basically every time with
>> non-threaded model). But I guess we could improve the performance
>> little bit anyway - using snprintfs are somewhat suboptimal and some
>> string related functions could be improved as well. I'll do that.
>
> just fyi, after the last version of joe orton's tzdata patch, i tried making
> various improvements (using mmapped regions instead of stdio file i/o, etc)
> but even with really ridiculous test cases the difference in startup time
> were negligable or non-existant.  so i think we should verify that there
> is a runtime performance issue we can and want to improve first.

True, after all (I did some testing) snprintf is ~20000 nanoseconds,
and strncpys were 4500-5000 nanoseconds.  But I still feel that
snprintf is a horrible way how to concatenate two strings :-).

>> $ cat /etc/timezone
>> America/Mexico_City
>> $ php -nr 'var_dump(date_default_timezone_get());'
>> string(15) "America/Chicago"
>
> out of curiosity, if you set it to use "System/Localtime" in php.ini,
> does it take the correct one?

Nope, and it probably could not, because Olson name (to my best
knowledge) is not encoded in zoneinfo file.

Ondrej
-- 
Ondřej Surý <ondrej at sury.org>
http://blog.rfc1925.org/