WordPress.org

Make WordPress Core

Opened 8 years ago

Last modified 6 years ago

#3962 closed task (blessed)

WordPress should adjust for DST ("location" appropriate) — at Version 20

Reported by: iacas Owned by: anonymous
Milestone: 2.8 Priority: high
Severity: normal Version: 2.1.2
Component: Date/Time Keywords: needs-testing
Focuses: Cc:

Description (last modified by lloydbudd)

WordPress should adjust for DST ("location" appropriate)

WordPress should be blog time "location" aware. "WordPress does not do daylight savings time (DST)"

WordPress respecting and adjusting to a blog's "location" is a regularly reported and frustrating issue. People forget about UTC offset as it is unfamilar in their other computing experiences.

Original report:

XML-RPC Incorrectly Handles New Daylight Savings Time

This problem is twofold, I believe. A little more information is here:
http://nslog.com/2007/03/12/wordpress_212_and_daylight_savings

Problem 1: Posting
When posting content via an XML-RPC client, WordPress subtracts one hour from the time. Running "date" on the command line or via PHP's "date()" function returns the correct time. Setting the time in the WordPress (wp-admin) web interface does not "subtract" an hour.

Problem 2: Viewing
Despite the server returning the correct time via "date" on the CLI or via PHP's "date()", articles set to publish at 10:00 will not appear until 11:00.

Change History (20)

comment:1 follow-up: @westi8 years ago

  • Keywords reporter-feeback added
  • Milestone 2.1.3 deleted
  • Priority changed from high to normal

WordPress does not do DST.

AFAIK any time related offset changes that WordPress makes are based on the time difference specified in the admin ui.

Please provide more information as to the specific setup and problem.

comment:2 in reply to: ↑ 1 ; follow-ups: @iacas8 years ago

Replying to westi:

WordPress does not do DST.

WordPress should rely on the server for its date and time. We're living in the 21st century. Manually changing the time two times per year is so 1995.

comment:3 in reply to: ↑ 2 @Nazgul8 years ago

WordPress should rely on the server for its date and time. We're living in the 21st century. Manually changing the time two times per year is so 1995.

My server is in the UK, I'm in Holland. I wouldn't be happy if the DST settings where managed by the server

comment:4 in reply to: ↑ 2 @westi8 years ago

Replying to iacas:

Replying to westi:

WordPress does not do DST.

WordPress should rely on the server for its date and time. We're living in the 21st
century. Manually changing the time two times per year is so 1995.

Except that in many if not most cases the server and the end-user will be in different timezones - so relying on the server for time won't help.

comment:5 follow-up: @Otto428 years ago

Part of the problem is described by westi (the user needs the ability to be in a different timezone than the server) and part of the problem is that the timezone stuff in PHP versions earlier than PHP5 is quite weak.

It would be nice to abstract the timezone handling out into some functions so that we could include support for the date_default_timezone_set() stuff for PHP5 systems, and continue with the existing support for PHP4 systems. This would allow it to handle DST changes automatically (assuming the system itself supported it correctly). Timezones would need to be a string from a big list, like "America/Chicago" and so forth (full list here: http://php.net/manual/en/timezones.php ).

It might also be able to support this sort of thing for PHP4 by using the putenv('TZ=...') workaround.

comment:6 in reply to: ↑ 5 ; follow-ups: @iacas8 years ago

Replying to Otto42:

Part of the problem is described by westi (the user needs the ability to be in a different timezone than the server) and part of the problem is that the timezone stuff in PHP versions earlier than PHP5 is quite weak.

Virtually every server I've seen in the past allows the user to set the time zone in which they reside. It's not universal, but it's rather common. How about an option to "use server time" or to specify your own UTC offset?

In PHP, "date()" works reliably if the user can set the time zone.

comment:7 in reply to: ↑ 6 ; follow-up: @westi8 years ago

Replying to iacas:

Replying to Otto42:

Part of the problem is described by westi (the user needs the ability to be in a different timezone than the server) and part of the problem is that the timezone stuff in PHP versions earlier than PHP5 is quite weak.

Virtually every server I've seen in the past allows the user to set the time zone in which they reside. It's not universal, but it's rather common. How about an option to "use server time" or to specify your own UTC offset?

Yes, the server will have a timezone set on it. But most servers on which WordPress is installed support multiple Users who are quite conceivably in different timezones.

comment:8 in reply to: ↑ 6 @Otto428 years ago

Replying to iacas:

Virtually every server I've seen in the past allows the user to set the time zone in which they reside. It's not universal, but it's rather common. How about an option to "use server time" or to specify your own UTC offset?

In PHP, "date()" works reliably if the user can set the time zone.

That's sort of the problem. We do have the ability for a user to set their own offset from UTC, in a number of hours (-6, for example). What we *need* is a more standard timezone handling mechanism.

Generally, you don't set your timezone as a UTC offset. You set it as a location. Like America/Chicago, or Europe/Amsterdam or what have you. This not only sets your offset, but regional variations as well.

In PHP4, this was all based off the contents of the TZ environment variable.
In PHP5, they added functions to set it more directly, like date_default_timezone_set().

In either case, date() will reliably give the correct local time for any given timezone *if* one of those are set properly. Wordpress is doing neither. It's just multiplying the offset by 3600 and adding it to the time output wherever it needs a date. All these can be eliminated with proper timezone handling.

comment:9 in reply to: ↑ 7 @Otto428 years ago

Replying to westi:

Yes, the server will have a timezone set on it. But most servers on which WordPress is installed support multiple Users who are quite conceivably in different timezones.

That's another problem. Wordpress can have more than one User, but it cannot have more than one time offset. This could be handled as well.

Note that this could conceivably be done with a plugin as well. By setting the built in offset to zero, you can then use the right methods to do it. Tell you what, I'll work out a quick example sometime next week and post it up for everybody to look at, and try on their systems. Because of the version differences, we'd probably want to test it on several platforms/servers/PHP versions.

comment:10 @ryan8 years ago

Now that contemporary versions of PHP ship with a version of the Olson database via timezonedb, proper DST support is more attainable. It's still a pain in the ass to get it right and a fairly pointless endeavor for php4.

http://laughingmeme.org/2007/02/27/looking-at-php5s-datetime-and-datetimezone/
http://www.torenware.com/handbooks/timezones
http://drupal.org/node/11077

comment:11 @molecularbear8 years ago

I have been experiencing "Problem 2: Viewing" that the original poster describes (all dates appear correct, server time is correct, I have adjusted the UTC offset in WP, etc). I found that newly published posts in the database had the correct post_date, but that the post_date_gmt was off by one hour. I tracked the problem to function get_gmt_from_date in formatting.php, but found that the issue ran deeper than the WP code.

Function gmmktime depends upon function mktime. I am running PHP 4.3.4, but according to the PHP ChangeLog, there was a bug in mktime that was fixed in PHP 4.3.6.

To see if you have the same problem, check your PHP version with php -v, or run this:

echo gmdate('Y-m-d H:i:s', gmmktime(0, 0, 0, 4, 20, 2007)) . "\n";

The correct output is this:

2007-04-20 00:00:00

The problematic output is this (i.e., an hour off):

2007-04-20 01:00:00

comment:12 @Nazgul8 years ago

  • Milestone set to 2.4 (future)

comment:13 @thee178 years ago

  • Summary changed from XML-RPC Incorrectly Handles New Daylight Savings Time to XML-RPC Incorrectly Handles New Daylight Savings Time hunt-irrelivent

I think this problem should not be fixed

comment:14 @thee178 years ago

  • Keywords hunt-irrelivent added
  • Summary changed from XML-RPC Incorrectly Handles New Daylight Savings Time hunt-irrelivent to XML-RPC Incorrectly Handles New Daylight Savings Time

comment:15 @darkdragon8 years ago

  • Keywords hunt-irrelevant added; hunt-irrelivent removed

comment:16 @josephscott8 years ago

  • Cc josephscott added

comment:17 @thee178 years ago

  • Keywords hunt-irrelevant removed
  • Resolution set to invalid
  • Status changed from new to closed

comment:18 @lloydbudd8 years ago

  • Keywords reporter-feeback removed
  • Milestone changed from 2.4 to 2.6
  • Resolution invalid deleted
  • Status changed from closed to reopened

comment:19 @lloydbudd8 years ago

  • Component changed from XML-RPC to General
  • Description modified (diff)
  • Summary changed from XML-RPC Incorrectly Handles New Daylight Savings Time to WordPress should be blog time "location" aware

Re-opening and setting for consideration in a future release (PHP5?)

The more basic issue of WordPress respecting and adjusting to a blog's "location" is a regularly reported and frustrating issue. People forget about UTC offset as it is unfamilar in their other computing experiences.

comment:20 @lloydbudd8 years ago

  • Description modified (diff)
  • Summary changed from WordPress should be blog time "location" aware to WordPress should adjust for DST ("location" appropriate)
Note: See TracTickets for help on using tickets.