#3522 closed defect (bug) (no action required)
Fix timezone != GMT creates wrong "posted xyz ago" dates
Reported by: | sboisvert | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Core | Keywords: | close |
Cc: | stboisvert@… |
Description
Our server being on Eastern Time, we had all posts off by 4h.
The problem was that Buddypress has all internal times in GMT, but at one point uses strtotime which will convert the time to the date.timezone setting (actually whatever http://www.php.net/manual/en/function.date-default-timezone-get.php returns).
This patch adds the timezone offset of the same timezone used by strtotime to the calculations.
Attachments (1)
Change History (11)
#1
@
13 years ago
- Keywords has-patch needs-testing added
- Milestone changed from Awaiting Review to 1.5
#2
@
13 years ago
- Keywords reporter-feedback added
I can't replicate this. sboisvert, with what version of BP are you having this issue?
#3
@
13 years ago
iirc, this only manifests itself in certain setups, and in certain components. It's a hard one to pinpoint and has been lingering for years (probably an old ticket about it too.)
#4
@
13 years ago
- Milestone changed from 1.5 to 1.6
Worth noting we use strtotime() in 51 other places in BuddyPress core. This probably needs more attention than we can give it in 1.5. Moving to 1.6 unless someone wants to do some serious investigation, seriously quickly.
Seriously. :)
#5
@
13 years ago
fwiw, I thought we had fixed all the timestamp bugs in one of the mid-1.2.x releases
#6
@
13 years ago
- Cc stboisvert@… added
Sorry for the delay in replying.
This is running 1.5B2 on WP 3.2.1
In our current set up we have the Servers running on GMT, but php has its config set in the htaccess to
php_value date.timezone "America/Toronto"
We also have our wordpress timezone setting set to the same value.
#7
@
13 years ago
I'm with DJPaul on this. I've tried multiple combinations of timezone settings. The most convoluted was where PHP was set to one TZ, the server to another, and WP to another. I couldn't break anything. I then read the PHP documentation on the issue. As far as PHP is concerned, this is how the tz is determined (http://www.php.net/manual/en/function.date-default-timezone-get.php):
- The date_default_timezone_set() setting
- the TZ environment variable (PHP prior to 5.3.0)
- the date.timezone ini option
- the host OS
- if all the above fail, default to UTC
WP uses date_default_timezone_set( 'UTC' ) very early on (in wp-settings.php) which means that to PHP, we're always on UTC. No matter your WP or server setup, all time is UTC, get_gmt_from_date() being the only exception. I think it's safe to mark this as invalid, but just in case:
@sboisvert, can you provide some more details? Are you having this issue on all new posts, or is the time only off on old posts? With what specific components are you having this issue? What's your PHP version, and are you on a Windows or Linux server?
#9
@
13 years ago
- Keywords close added; has-patch needs-testing reporter-feedback removed
- Resolution set to invalid
- Status changed from new to closed
To make a long story short, one of our default mu-plugins changed the timezone settings after WordPress had initialized, this therefore caused the bug to show up. I really should of tested this more thoroughly on a clean install before reporting a patch, I just googled, saw a bunch of people had the same problem, (this is I suspect from before the fixes done in 1.2.x) and assumed I had found a solution to a real problem. I'm very sorry for wasting the community's time and have obviously learnt my lesson in terms of always verify against a clean install first (no matter what google says). Again my apologies.
Sweet idea. Moving to 1.5 to get eyes on it.