>> Which is why a pseudo-timezone called System is needed so that guesses
>> do not have to be made. The extension would then convert
>> /etc/localtime to its internal time zone description format or just
>> use system-provided APIs as it used to do before PHP 5.1 if I
>> understand correctly.
>>
>>> That's a really bad idea, as we've discussed before on this list.
>
> <snip>
>
>> Perhaps I am a bad searcher; I would appreciate if you pointed me at
>> some of the past discussion.
>
> http://marc.info/?t=119988823700001&r=1&w=2 is what it was I think.
Thanks. The thread was an interesting read but my suggestion is different
from the one discussed there: I propose adding _one_ special time zone
that will use the /etc/localtime file or system-provided APIs (only that
time zone!), not using the /usr/share/zoneinfo directory instead of the
built-in time zone database. So existing code would work just as before
but in addition one could write
date_default_timezone_set('System');
and get direct access to the system's own notion of local time, so e. g.
date_default_timezone_set('System');
echo date('r');
would be equivalent to the C code
char date[256];
time_t now = time(NULL);
strftime(date, 256, "%a, %d %b %Y %H:%M:%S %z", localtime(&now));
fputs(date, stdout);
While PHP does focus on server-side Web programming, it is not limited to
it and is a general-purpose scripting language. It can be used to run
'client-side' scripts just like the shell, Perl, Python and Ruby can be
used, and in fact it can also be similarly used to run command-line (or
even graphical) utilities on servers, and even in Web pages one might
sometimes explicitly want to use the server time. In all these cases
system time needs to be used, and the only reliable way to do so is to
refer directly to the local time zone description and/or local time APIs
provided by the system. Being independent of the system in other cases is
also important, and so adding a single special time zone that trusts the
system to the already-existing set of time zones that do not trust the
system seems not just a compromise but a win-win solution.
For now I will find where all my php.ini files are, add date.timezone and
write a script to edit them all at once when I move from one time zone to
another. I might even schedule it to run regularly and pick up changes
automatically or even make it a daemon if I was constantly travelling.
This will normally work for me even if it somewhat annoys me, but if I
forget to run my script or if I decide for any reason to move to (or
pretend I am in) some obscure time zone PHP does not know, I will easily
be able to explain that to my system, including virtually all other
software I use, but not to PHP.
Recommending server administrators to set date.timezone to provide
scripts with the ability of using the server's local time also has a
negative consequence: poorly-written software that uses local time
without caring about time zones will stop generating the warnings it
generates now. In the end this might well encourage such poor practices
more than discourage them.
Finally, a word on removing support for the TZ environment variable in
particular: once again this makes good sense for server-side software but
is bad for client-side software, as TZ is a standard way of telling
software you launch which time zone you want it to work in. When the
local time API used by this software supports TZ (and just about
everything supports it), it just works, without the programmer doing
further work such as adding command-line options and in fact without them
even knowing that you use this functionality. For example, I have used
this to make commits on a remote machine (in an SSH session) with commit
dates recording my local time zone instead of the (properly used!) system
time zone of the remote machine.
--
Oleg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
