[wp-trac] [WordPress Trac] #39595: date_default_timezone_set in wp-settings.php is set prematurely and ignorantly, regardless of other defined settings

[WordPress Trac]

#39595: date_default_timezone_set in wp-settings.php is set prematurely and
ignorantly, regardless of other defined settings
-------------------------------+------------------------------
 Reporter:  mkormendy          |       Owner:
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Date/Time          |     Version:  4.7.1
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------

Comment (by Otto42):

 Realistically, the timezone handling in WordPress is sub-optimal because
 at the time it was implemented, WordPress still supported PHP 4, which
 lacked solid timezone support.

 Would it be possible to replace all the time handling in WordPress with
 PHP 5 methods, using the proper default timezone set to the local
 timezone, and then using gmdate() and date() appropriately? Sure.

 The amount of effort required to do so is bordering on insanity, but there
 are not actually as many backwards compatibility breaks as you might
 think.. Any WP dependent code (plugins, themes) are using WordPress
 functions for date/time display for the most part, and those outputs would
 remain unchanged.

 So the question is what would be the benefits? Well, there probably would
 be a noticeable speed improvement. The timezone adjustment code is
 implemented as a filter and it's called far too often in normal usage. A
 lot of the underlying time handling code could be simplified to various
 wrappers around date() or gmdate(), speeding them up. Many of the odder
 functions in WordPress related to such could be changed to simply be those
 native calls in the first place, or calls to date_i18n() when appropriate.

 Basically, it's a lot of work, without a lot of immediate benefit, and
 would also necessitate a heck of a lot of unit tests be written to verify
 it along the way. In that respect, I think the additional unit tests being
 made at all would probably be the main benefit from such a venture.

 So, definitely worthy of consideration for the long term, but probably
 pretty low priority. Perhaps a migration path forward to switch everything
 to native date handling is something that could be considered.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39595#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform