On 8.10.2005 15:30 Uhr, Zeev Suraski wrote:
I've been away from email for the last couple of weeks - read through
the timezone thread, and didn't really see a conclusion.
IIRC the conclusion was, that Derick tries to make the TZ detection
better (which was the only BC problem, AFAIK). And according to him,
that's now almost solved (except some weird problems on Windows).
Yep, even on windows is it almost working at 100% :) And I'm having much more success with the new code, specially on Windows and Solaris.
He even made a pecl package for updating the TZ data easily should that
change.
Upgrading the TZ data should be as easy as upgrading a PECL package.
If the TZ detection works reliable, I don't see any reason to revert or
postpone Dericks work, the timezone handling of his implementation is so
much better than the old one, it's really worth the upgrade for everyone
having to deal with different timezones.
Yes it shouldn't be reverted. I think it is working well, and it is already covered by a large amount of test cases, so the BC breaking chances are minimal.
Nuno
Just my 2 cents.
chregu
My suggestion is to restore the old code in its entirely, and introduce
the new implementation as new functions with a proper prefix, a-la PHP
2005. I think it's better than an INI entry, and it should be fairly
straightforward to implement.
I don't think anybody is underestimating Derick's efforts towards
building this new date functionality. I certainly don't. I also don't
see any reason to break compatibility in something as basic as this, so
this should be introduced either as a new (preferably) or optional (less
preferably) feature.
Zeev