Skip to:
Content

BuddyPress.org

Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#3522 closed defect (bug) (no action required)

Fix timezone != GMT creates wrong "posted xyz ago" dates

Reported by: sboisvert's profile 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)

calculate_offset.patch (616 bytes) - added by sboisvert 13 years ago.

Download all attachments as: .zip

Change History (11)

#1 @johnjamesjacoby
13 years ago

  • Keywords has-patch needs-testing added
  • Milestone changed from Awaiting Review to 1.5

Sweet idea. Moving to 1.5 to get eyes on it.

#2 @cnorris23
13 years ago

  • Keywords reporter-feedback added

I can't replicate this. sboisvert, with what version of BP are you having this issue?

#3 @johnjamesjacoby
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 @johnjamesjacoby
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 @DJPaul
13 years ago

fwiw, I thought we had fixed all the timestamp bugs in one of the mid-1.2.x releases

#6 @sboisvert
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 @cnorris23
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):

  1. The date_default_timezone_set() setting
  2. the TZ environment variable (PHP prior to 5.3.0)
  3. the date.timezone ini option
  4. the host OS
  5. 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?

#8 @DJPaul
13 years ago

Also, is your WordPress timezone set to something like "London", or like "+0" ?

#9 @sboisvert
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.

#10 @johnjamesjacoby
13 years ago

  • Milestone 1.6 deleted
Note: See TracTickets for help on using tickets.