WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #25365, comment 9


Ignore:
Timestamp:
06/26/2014 02:00:07 PM (5 years ago)
Author:
buley
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #25365, comment 9

    initial v1  
    1 `date_default_timezone_set('Asia/Jerusalem');` is in fact the issue. For me of course it's my own `America/New_York`, needed for a 3rd party Google Analytics library on which we rely.
     1I can confirm for you that your `date_default_timezone_set('Asia/Jerusalem');` is in fact the configuration "issue" that causes this behavior. For me of course it's my own `America/New_York`, needed for a 3rd party Google Analytics library on which we rely.
    22
    33In a setup where WordPress is a component in a larger system, using `date_default_timezone_set()` is commonplace. In fact if you don't set this you'll get the "It is not safe to rely on the system's timezone settings" warning telling you that you should use this, or "the date.timezone setting" which I presume will have a similar effect.
    44
    5 A proposed "fix" is can be as simple as using `$modified` for the `human_time_diff()`. Otherwise, removing the `date_default_timezone_set()` call seems necessary (which seems unnecessary).
     5I've found no filters or other way around this that doesn't require core modification or client-side hackery. A proposed "fix" is can be as simple as using `$modified` for the `human_time_diff()`.
     6
     7Removing the `date_default_timezone_set()` call seems necessary but that's unacceptable in my configuration, and unfortunately the difference is somewhat undermining our user confidence.