NYCPHP Meetup

[Peter Sawczynec]

This is an excellent lucid recap. Thank you. 

So my take away is that PHP date() et al. is fairly adept at handling
time zones as based upon a relatively uniform database of
internationally-recognized time zone names, but that D.S.T. as a
changeable entity is not handled. So it appears to me that at this time
one must reach into one's code and put in a fix for the shortly upcoming
new non-standard D.S.T. associated to the several time zones in the U.S.
and that PHP is at this time not prepared to handle this change until it
is added into the core functions at a later date and that such new
D.S.T. update is not currently incorporated in an version of PHP 5.x

Thanks again, 

Peter




-----Original Message-----
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org]
On Behalf Of Jon Baer
Sent: Tuesday, February 27, 2007 10:12 AM
To: NYPHP Talk
Subject: [Norton AntiSpam] Re: [nycphp-talk] New Daylight Savings Time in
U.S. Coming Up Very Soon


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