Derick Rethans wrote:
[...], if you have any idea on how to make things better, please step forward. I already spoke with the doc folks how to document all the timezones that we now support.
I've learned about the limitations of the old date/time functions some time ago, so I had to implement some of the features you implemented in user space and know about some of the problems involved here. I think the new date extension/features are very valuable for PHP.
But what I don't understand is, why this was implemented into old date/time functions, and not as a new extension with a new, nice OO interface like date_time (e.g.: http://cvs.php.net/co.php/pecl/date/docs/examples/sample1.php ) would have provided. So you could completely avoid all BC problems and make it much easier to work with dates/times if you choose the new extension with a new interface (see sample above). AFAIR there were plans to add an OO interface to the current date extension, but what is the advantage of having the same codebase behind the old date/time functions and a new OO interface?
As we can see here, this will break a lot of existing code, because most people who will never need the new date/time features (who have written a lot of code, valid for PHP 5.x, 4.x...), are forced to use this BC breaking code - IMHO without the need. And probably this will not be very easy to fix for many people.
People needing the new features (like me) would be happy if old date/time behave the same as before 5.1, and if there is a new OO interface for the new extension.
Perhaps it's a good idea to restore the old date/time functions before PHP 5.1 release, and add the new functions + OO interface to the new developed date codebase, and make it a seperate extension with different interface in the documentation.
Or why is the change of old functions like date() needed/useful? best regards Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
