randell

You can do what you like (as I’m sure you know) but this us a PHP 5.3.0 issue and not a WordPress issue.

Actually, it’s both, since WordPress is using PHP and is affected by its changes.

Yes, I agree that we can do what we like, but in this case it would only mean fixing the problem every time a WordPress installation breaks when PHP is upgraded *pointing to the original problem*.

Why not?

Again, it risks breaking (or at least messing up) existing WordPress installations when PHP is upgraded by someone who is not aware that doing so needs modifying of the date.timezone directive. Placing the date_default_timezone_set() function on the core makes WordPress installations more sturdy. When I say putting it in the core, I mean making it available for the next release without us having to modify our WP installations anymore.

I do not understand why it is better to modify php.ini instead of adding the date_default_timezone_set() function in the WordPress core. From the description of date_default_timezone_get(), the highest in the preference is “Reading the timezone set using the date_default_timezone_set() function (if any)”. And it makes sense since it would not be wise to rely on the system’s php.ini settings for the timezone. Yes, it would be better if the directive for date.timezone is set but WordPress, or any PHP project, should rely on the directive being set. It might be better to add a configurable variable with a default value set for the date_default_timezone_set() function.