While not really a definitive answer + a bit old, here is an
interesting recap on this type of subject from a Zend weekly (sorry
kinda long but informative) ...
-snip-
TLK: The date wars
By far the longest thread of the week was started by Stas Malyshev,
who was appalled to discover that, following an upgrade to PHP_5_1,
all the machines in Zend's Israel office returned UTC dates and spat
out warnings when PHP's date() was called. He guessed that the built-
in library in the new ext/date didn't recognize his timezone, and
went on to suggest that using a library with an internal fixed
timezone list other than that used by the operating system was 'an
extremely unfortunate choice'. He reasoned that any qualified
sysadmin knows how to set up the timezone on the user's operating
system, but he'd no idea how to make PHP recognize his timezone now.
Was there any way to fix that? If so, it should be explicitly stated
in the manual; if not, it needed to be fixed as soon as possible.
Derick Rethans defended his baby, advising Stas that he should use
the date.timezone setting in his php.ini and that this would've been
evident had Stas been running under E_STRICT. However, if the name
really wasn't being recognized, the team could add it to the
database... He disagreed that the timezone list should match that of
the OS, pointing out that an application relying on timezones has
zero portability that way. Stas retorted that the date.timezone
setting was the part complaining that it didn't know his timezone
(IDT). He saw a problem in Derick's statement that the team could add
it to the database, and wondered how many others out there hadn't
been added yet? 'So we will be fixing it for years and still get it
not working in some places - while before the "improvement" it
worked!' He couldn't see how Derick ever expected to have the full
timezone list, given that both Unix and Windows allow their timezone
databases to be extended and timezone rules to be changed. Even if
Derick added the name there, there was no guarantee that the rules
the library uses would match the rules the rest of the OS uses. How
could he be certain that PHP applications wouldn't change from DST to
standard time a week earlier than the rest of the applications on a
given box? As for portability, Stas found it more seriously annoying
when the application running on his own platform suddenly stopped
working and couldn't be fixed without patching C code.
Derick asserted that a timezone abbreviation should never be used in
the first place; the real name for Stas' timezone is ' Asia/
Tel_Aviv', and that won't change, whereas IDT is an arbitrary
description of Israel's local time in combination with Daylight
Savings Time. His timezone database is updated from the Olson tz
database, which is also used by the GNU C Library, and therefore all
open source operating systems. If the OS didn't use that database, it
would be the distribution that was incorrect and not PHP. The problem
with OS services is that the timezone abbreviations they use are not
unique, and don't offer a solid way of handling complex work. Having
to set date.timezone was the only penalty for having superior
timezone handling in PHP, and Derick felt that this was negligible;
nobody needs to change any C code in order to pick the correct
timezone as a setting. However, if you didn't set the timezone in any
of the three ways open to you via PHP, the fallback - failing a
'magical' guess from those operating systems that support it - would
be UTC.
Stas argued that breaking working applications was a Bad Thing -
timezone abbreviations given by the system had been understood by PHP
until now, and he didn't see why that should suddenly stop being the
case. Besides, if you didn't use the system's rules you would have
serious problems keeping them up to date - wouldn't he need to
reinstall PHP to pick up Derick's timezone database fixes? As for
now, PHP was totally crippled, since he couldn't use date() unless he
somehow guessed what the new library wanted from him. What would
happen when he wanted to install his application on a user's system?
The library itself doesn't offer any assistance, it simply refuses to
work until you find the correct name for the timezone, whereas before
it 'just worked', the same as all the other applications on his box.
Why should PHP need special handling to do that? And how had Derick
arrived at the setting he needed, where was that documented? How
would he find out what his mythical client needed to use? Stas wrote
that he didn't have a problem with date() gaining additional
capabilities - he just didn't see why this should be at the cost of
making previously working code require additional configuration which
couldn't possibly be automated, given that the configuration value
doesn't exist anywhere in the system settings. Wasn't there a way to
use the old, working version of date() so that - without anything
being set manually - it would work as it did under PHP 4?
Derick explained that the 'magic guess' works in many cases, just not
in the case of IDT. He didn't want to see any of the code relying on
the system settings, but agreed that the list of available settings
should be documented in the near future. Ilia Alshanetsky backed
Derick, saying that 'Asia/Tel_Aviv' was the standard name for Stas'
timezone across most systems, whereas he'd just run some tests and
found that neither Linux, FreeBSD nor Solaris understood 'IDT'. The
way Derick had implemented the date library ensured a constant,
unchanging list of available timezones. This wasn't the case when
system settings were relied upon.
Stas continued to argue his corner at some length, suggesting that
there could at least be a function named system_date() which would
work the same way the old date() function used to work. He wanted to
work with the system's settings, and suspected that the majority of
the use cases for date() would be happy with that behaviour. Zeev
Suraski agreed with Stas, saying that he hadn't seen a single good
justification yet for the fact that a working application suddenly
stopped working following an upgrade. The code in question didn't
have a hard-coded timezone abbreviation, it simply used a system
setting, and Zeev didn't think this was likely to be an approach
unique to Zend's in-house developers. He ended soberly, 'The fact
that date() now tries to be intelligent about it but fail is a real
problem.'
By now Derick was also coming under attack from Pierre-Alain Joye
over having ext/date as part of the core in the first place, and
threw out a plea for an end to the 'bickering'. He wrote that he'd
already spoken with the documentation team about how to document the
timezones PHP now supports, and asked for anyone with any ideas about
how to make things better to step forward. He went on to say that the
reason IDT isn't in his timezone abbreviations list is that the
legacy code behind strtotime() already uses IST for Indian Standard
Time, and not for Israel Standard Time; allowing IST (and therefore
IDT) for Israel would create conflict here.
Lukas Smith summarized the wider debate, saying that keeping both
versions of the date() implementation might ease the short-term pain
but would lead to a waste of development resources, and it was
inevitable that PHP users would eventually be forced to adapt to the
new solution. The real question was when 'eventually' should be?
'Should there be an interim period where we keep both implementations?'
Meanwhile, Edin Kadribasic backed Pierre's chief argument about
keeping the date extension in PECL 'for all the fancy stuff' and
retaining the old date implementation in the core; Ron Korving popped
his head above the parapet long enough to note that changing the
approach now could postpone PHP 5.1's release date; and Stas got into
a fight with Lukas over the meaning of 'portable'. So I asked a
stupid question; why isn't there a default setting that's set by the
system date() data?
Stas responded first, saying that if that were the case he'd be the
first to applaud the work done on ext/date, but he understood Derick
to have said it wasn't possible. Derick replied that actually this is
exactly what he was trying to achieve; it's just that the fallback
abbreviations (IDT) haven't all been linked to their respective
timezone identifiers yet (Asia/Tel_Aviv). He went on to say that he
now had a patch that will allow the timezone guessing code to check
against the GMT offset as well as the abbreviation, and was looking
into ways of creating the database for that. Stas raised the unlikely
spectre of two timezones sharing the same abbreviation and current
GMT offset but different rules, but you could see he was tiring. I
put in a plea for a more locale-aware E_STRICT message offering the
precise string to put into the php.ini, but Derick explained (off-
list) that this wouldn't be possible to implement in the way I
envisioned, due to the fact that some timezone areas have multiple
names.
Rasmus Lerdorf echoed Lukas' earlier concern; should we take the BC
hit now, and have clean and consistent date/time handling, or should
we keep BC, hold up the 5.1 release for a couple of weeks, and
support two date/time systems forever? His personal inclination was
towards keeping BC, but he felt there was a lot to be said for not
having two different implementations. Perhaps everyone who argued so
strongly over the issue should come on board to help with testing
now, and help make the new implementation back compatible.
Andi Gutmans replied that he'd only agreed to have ext/date in PHP
5.1 because Derick had promised it wouldn't break BC. As this
obviously wasn't the case, he hoped to see the ability to get back
the old behaviour, even if that had to be via an .ini setting. Wez
backed him, saying that date() in 5.1 should default to the old code
and have a toggle for the new implementation. There should also be a
deprecation notice to warn users about the move planned for PHP 6...
Andi agreed and asked Derick to return the support for the old
functionality and create an .ini option, saying that he didn't
believe 5.1 could be released in its current state. Derick argued
that the code under discussion wasn't the code Andi was referring to,
which is still disabled, and Jani Taskinen pointed out that this
wasn't a bug fix release and users didn't have to upgrade to it. Wez
argued that 'to completely replace the default implementation of a
core function... is quite a risk', and that the PHP project is big
enough now to have a responsibility to its users. Whether PHP 5.1 was
intended to be a bug fix release or not was irrelevant; he called for
a solid, reliable approach to software development, and espoused the
Solaris team's approach (of having two sets of APIs). Andi backed him
all the way over this.
Back to the topic in hand, Moshe Doron raised the subject of non-
rules; 'Here in Israel, there is stupid habit to change the DST range
almost each year. Should I expect that today's date() function will
give me the wrong date next year?' If so, he reasoned, it would
constitute a fatal BC break for Israeli users. Andi clarified this: a
parliamentary decision is taken with regard to daylight savings time
each year, and Israeli sysadmins generally have an automated way of
getting the updated timezone file from a central distribution server
and dropping it into the system. Israel probably isn't the only
country with a dynamically changing database, and if Derick's
implementation couldn't support that, the old API would have to be
supported. However, Derick had done his homework, and broke the news
that a permanent daylight savings rule was created for Israel this
year. Brazil was the only other country he knew of in that situation.
His solution was to create a PECL extension incorporating an updated
timezone database, which would be used by the core functions when
installed. Re-introducing the old API would mean re-introducing
around 20 known bugs into PHP; the whole reason for the new API was
that the old one was broken. Wez argued that having 20 known bugs was
better than having an unknown quantity of unknown bugs, and asked if
Derick could honestly guarantee that there wouldn't be a BC breakage
by the time of release? Derick replied that there wasn't any BC
breakage if people had the .ini directive set correctly anyway, but
that the guessing mechanism should cover the majority of cases -
nobody could guarantee a 100% success rate.
Short version: Timezone guessing is (theoretically) correct in most
cases now, and there will be a PECL extension to cope with Brasilian
timezone updates etc.
-snip-
_______________________________________________
New York PHP Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
NYPHPCon 2006 Presentations Online
http://www.nyphpcon.com
Show Your Participation in New York PHP
http://www.nyphp.org/show_participation.php
