Date/Time and WP

Discussion:

Date/Time and WP

Dobri

2013-07-17 12:45:12 UTC

Hey guys,

From my understanding, when dealing with date and time, WordPress, because of PHP 4 legacy support, sets timezone to UTC and does its own calculations based on the timezone in options. So, when writing plugins, what would be the correct approach to making sure correct timezone is used? Should I use built-in functions like date and somehow specify timezone every time I access them? Or are there any WordPress functions created for that purpose? Any help with this appreciated. Thanks!

~Dobri

Ryan McCue

2013-07-17 12:48:02 UTC

Permalink

See http://core.trac.wordpress.org/ticket/24730

Here's how I handle it:

protected function get_timezone() {
$tzstring = get_option( 'timezone_string' );
if ( ! $tzstring ) {
// Create a UTC+- zone if no timezone string exists
$current_offset = get_option( 'gmt_offset' );
if ( 0 == $current_offset )
$tzstring = 'UTC';
elseif ($current_offset < 0)
$tzstring = 'Etc/GMT' . $current_offset;
else
$tzstring = 'Etc/GMT+' . $current_offset;
}
$zone = new DateTimeZone( $tzstring );
return $zone;
}

--
Ryan McCue
<http://ryanmccue.info/>

William P. Davis

2013-07-17 12:56:47 UTC

Permalink

date_i18n is a fantastic function that will make sure the date and time is returned in the same timezone set in the WP settings
Sent from my BlackBerry

-----Original Message-----
From: Ryan McCue <***@rotorised.com>
Sender: "wp-hackers" <wp-hackers-***@lists.automattic.com>Date: Wed, 17 Jul 2013 22:48:02
To: <wp-***@lists.automattic.com>
Reply-To: wp-***@lists.automattic.com
Subject: Re: [wp-hackers] Date/Time and WP

--
Ryan McCue
<http://ryanmccue.info/>

Dobri

2013-07-17 13:01:24 UTC

Permalink

Awesome, exactly what I was looking for. Thanks William! Just a sanity check, timestamps are just timestamps and are not affected by timezones, correct? As in, I can still use time(), time()+DAY_IN_SECONDS, etc.?

~Dobri

Post by William P. Davis
date_i18n is a fantastic function that will make sure the date and time is returned in the same timezone set in the WP settings
Sent from my BlackBerry
-----Original Message-----
Subject: Re: [wp-hackers] Date/Time and WP

See http://core.trac.wordpress.org/ticket/24730
protected function get_timezone() {
$tzstring = get_option( 'timezone_string' );
if ( ! $tzstring ) {
// Create a UTC+- zone if no timezone string exists
$current_offset = get_option( 'gmt_offset' );
if ( 0 == $current_offset )
$tzstring = 'UTC';
elseif ($current_offset < 0)
$tzstring = 'Etc/GMT' . $current_offset;
else
$tzstring = 'Etc/GMT+' . $current_offset;
}
$zone = new DateTimeZone( $tzstring );
return $zone;
}
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Alex King

2013-07-17 13:03:29 UTC

Permalink

Be aware of this too: http://core.trac.wordpress.org/ticket/20328

Cheers,
--Alex

http://alexking.org | http://crowdfavorite.com

Dobri

2013-07-17 12:57:49 UTC

Permalink

Thanks Ryan! When would a timezone_string not exist though? Wouldn't that simply mean settings were not touched, therefore it's some default (I'd guess UTC?)

~Dobri

Post by Ryan McCue

Ryan McCue

2013-07-17 13:06:11 UTC

Permalink

Post by Dobri
Thanks Ryan! When would a timezone_string not exist though? Wouldn't that simply mean settings were not touched, therefore it's some default (I'd guess UTC?)

--
Ryan McCue
<http://ryanmccue.info/>

Dobri

2013-07-17 13:14:13 UTC

Permalink

That makes sense. So, would you say there are performance benefits to using DateTime and the function you provided to just using date_i18n as William suggested? And is this a more robust method (for now) because of the bug in core that Alex brought up when dealing with date/time in DLS while it's currently not DLS and vice versa?

~Dobri

Post by Ryan McCue

Post by Dobri
Thanks Ryan! When would a timezone_string not exist though? Wouldn't that simply mean settings were not touched, therefore it's some default (I'd guess UTC?)

If the timezone is set to a manual offset (e.g. UTC+10), then the
timezone string won't be set (IIRC). In addition, older versions of
WordPress won't have the timezone_string setting and use gmt_offset instead.
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Ryan McCue

2013-07-17 13:18:26 UTC

Permalink

Post by Dobri
That makes sense. So, would you say there are performance benefits to using DateTime and the function you provided to just using date_i18n as William suggested? And is this a more robust method (for now) because of the bug in core that Alex brought up when dealing with date/time in DLS while it's currently not DLS and vice versa?

If you're working with relative time, you should definitely be using the
DateTime and DateTimeZone classes. DateTime natively understands
DateTimeZone and the DST transitions that can occur with it.

Performance-wise, creating a DateTimeZone instance is costly, but using
DateTime is fairly fast. If you're using this in production, I'd
recommend caching it:

protected function get_timezone() {
static $zone = null;
if ($zone !== null)
return $zone;

$tzstring = get_option( 'timezone_string' );
if ( ! $tzstring ) {
// Create a UTC+- zone if no timezone string exists
$current_offset = get_option( 'gmt_offset' );
if ( 0 == $current_offset )
$tzstring = 'UTC';
elseif ($current_offset < 0)
$tzstring = 'Etc/GMT' . $current_offset;
else
$tzstring = 'Etc/GMT+' . $current_offset;
}
$zone = new DateTimeZone( $tzstring );
return $zone;
}

(I'm using this in my JSON REST API, and the caching is fairly important
when using this for a list of posts.)

--
Ryan McCue
<http://ryanmccue.info/>

Dobri

2013-07-17 13:27:57 UTC

Permalink

Yeah, I figured some sort of caching is in place. Thanks for that, I think I've got a winner. Looks pretty robust to me and makes sense as a core function. I'd say think about caching on that trac ticket too. In any case, good luck with that and thanks for the help!

~Dobri

Post by Ryan McCue

If you're working with relative time, you should definitely be using the
DateTime and DateTimeZone classes. DateTime natively understands
DateTimeZone and the DST transitions that can occur with it.
Performance-wise, creating a DateTimeZone instance is costly, but using
DateTime is fairly fast. If you're using this in production, I'd
protected function get_timezone() {
static $zone = null;
if ($zone !== null)
return $zone;
$tzstring = get_option( 'timezone_string' );
if ( ! $tzstring ) {
// Create a UTC+- zone if no timezone string exists
$current_offset = get_option( 'gmt_offset' );
if ( 0 == $current_offset )
$tzstring = 'UTC';
elseif ($current_offset < 0)
$tzstring = 'Etc/GMT' . $current_offset;
else
$tzstring = 'Etc/GMT+' . $current_offset;
}
$zone = new DateTimeZone( $tzstring );
return $zone;
}
(I'm using this in my JSON REST API, and the caching is fairly important
when using this for a list of posts.)
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

Jacob Snyder

2013-07-17 16:11:53 UTC

Permalink

I have found that although date_i18n() is awesome, I also need to create my
timestamps using current_time('timestamp').

I wasn't getting timezone support from just date_i18n, until I started
using current_time. I haven't put much thought into, though, once my times
started getting recorded and retrieved as expected.

Send wp-hackers mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.automattic.com/mailman/listinfo/wp-hackers
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of wp-hackers digest..."
1. Date/Time and WP (Dobri)
2. Re: Date/Time and WP (Ryan McCue)
3. Re: Date/Time and WP (William P. Davis)
4. Re: Date/Time and WP (Dobri)
5. Re: Date/Time and WP (Dobri)
6. Re: Date/Time and WP (Alex King)
7. Re: Date/Time and WP (Ryan McCue)
8. Re: Date/Time and WP (Dobri)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Jul 2013 08:45:12 -0400
To: "Discussion list for WordPress developers."
Subject: [wp-hackers] Date/Time and WP
Content-Type: text/plain; charset=us-ascii
Hey guys,
From my understanding, when dealing with date and time, WordPress, because
of PHP 4 legacy support, sets timezone to UTC and does its own calculations
based on the timezone in options. So, when writing plugins, what would be
the correct approach to making sure correct timezone is used? Should I use
built-in functions like date and somehow specify timezone every time I
access them? Or are there any WordPress functions created for that purpose?
Any help with this appreciated. Thanks!
~Dobri
------------------------------
Message: 2
Date: Wed, 17 Jul 2013 22:48:02 +1000
Subject: Re: [wp-hackers] Date/Time and WP
Content-Type: text/plain; charset=ISO-8859-1

From my understanding, when dealing with date and time, WordPress,

because of PHP 4 legacy support, sets timezone to UTC and does its own
calculations based on the timezone in options. So, when writing plugins,
what would be the correct approach to making sure correct timezone is used?
Should I use built-in functions like date and somehow specify timezone
every time I access them? Or are there any WordPress functions created for
that purpose?
See http://core.trac.wordpress.org/ticket/24730
protected function get_timezone() {
$tzstring = get_option( 'timezone_string' );
if ( ! $tzstring ) {
// Create a UTC+- zone if no timezone string exists
$current_offset = get_option( 'gmt_offset' );
if ( 0 == $current_offset )
$tzstring = 'UTC';
elseif ($current_offset < 0)
$tzstring = 'Etc/GMT' . $current_offset;
else
$tzstring = 'Etc/GMT+' . $current_offset;
}
$zone = new DateTimeZone( $tzstring );
return $zone;
}
--
Ryan McCue
<http://ryanmccue.info/>
------------------------------
Message: 3
Date: Wed, 17 Jul 2013 12:56:47 +0000
Subject: Re: [wp-hackers] Date/Time and WP
Content-Type: text/plain
date_i18n is a fantastic function that will make sure the date and time is
returned in the same timezone set in the WP settings
Sent from my BlackBerry
-----Original Message-----
17 Jul 2013 22:48:02
Subject: Re: [wp-hackers] Date/Time and WP

From my understanding, when dealing with date and time, WordPress,

because of PHP 4 legacy support, sets timezone to UTC and does its own
calculations based on the timezone in options. So, when writing plugins,
what would be the correct approach to making sure correct timezone is used?
Should I use built-in functions like date and somehow specify timezone
every time I access them? Or are there any WordPress functions created for
that purpose?
See http://core.trac.wordpress.org/ticket/24730
protected function get_timezone() {
$tzstring = get_option( 'timezone_string' );
if ( ! $tzstring ) {
// Create a UTC+- zone if no timezone string exists
$current_offset = get_option( 'gmt_offset' );
if ( 0 == $current_offset )
$tzstring = 'UTC';
elseif ($current_offset < 0)
$tzstring = 'Etc/GMT' . $current_offset;
else
$tzstring = 'Etc/GMT+' . $current_offset;
}
$zone = new DateTimeZone( $tzstring );
return $zone;
}
--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
------------------------------
Message: 4
Date: Wed, 17 Jul 2013 08:57:49 -0400
Subject: Re: [wp-hackers] Date/Time and WP
Content-Type: text/plain; charset=us-ascii
Thanks Ryan! When would a timezone_string not exist though? Wouldn't that
simply mean settings were not touched, therefore it's some default (I'd
guess UTC?)
~Dobri

From my understanding, when dealing with date and time, WordPress,

------------------------------
Message: 5
Date: Wed, 17 Jul 2013 09:01:24 -0400
Subject: Re: [wp-hackers] Date/Time and WP
Content-Type: text/plain; charset=us-ascii
Awesome, exactly what I was looking for. Thanks William! Just a sanity
check, timestamps are just timestamps and are not affected by timezones,
correct? As in, I can still use time(), time()+DAY_IN_SECONDS, etc.?
~Dobri

date_i18n is a fantastic function that will make sure the date and time

is returned in the same timezone set in the WP settings

Sent from my BlackBerry
-----Original Message-----

Wed, 17 Jul 2013 22:48:02

Subject: Re: [wp-hackers] Date/Time and WP

From my understanding, when dealing with date and time, WordPress,

------------------------------
Message: 6
Date: Wed, 17 Jul 2013 07:03:29 -0600
Subject: Re: [wp-hackers] Date/Time and WP
Content-Type: text/plain; charset=us-ascii
Be aware of this too: http://core.trac.wordpress.org/ticket/20328
Cheers,
--Alex
http://alexking.org | http://crowdfavorite.com
------------------------------
Message: 7
Date: Wed, 17 Jul 2013 23:06:11 +1000
Subject: Re: [wp-hackers] Date/Time and WP
Content-Type: text/plain; charset=ISO-8859-1

Thanks Ryan! When would a timezone_string not exist though? Wouldn't

that simply mean settings were not touched, therefore it's some default
(I'd guess UTC?)
If the timezone is set to a manual offset (e.g. UTC+10), then the
timezone string won't be set (IIRC). In addition, older versions of
WordPress won't have the timezone_string setting and use gmt_offset
instead.
--
Ryan McCue
<http://ryanmccue.info/>
------------------------------
Message: 8
Date: Wed, 17 Jul 2013 09:14:13 -0400
Subject: Re: [wp-hackers] Date/Time and WP
Content-Type: text/plain; charset=us-ascii
That makes sense. So, would you say there are performance benefits to
using DateTime and the function you provided to just using date_i18n as
William suggested? And is this a more robust method (for now) because of
the bug in core that Alex brought up when dealing with date/time in DLS
while it's currently not DLS and vice versa?
~Dobri

Thanks Ryan! When would a timezone_string not exist though? Wouldn't

that simply mean settings were not touched, therefore it's some default
(I'd guess UTC?)

instead.

--
Ryan McCue
<http://ryanmccue.info/>
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers

------------------------------
Subject: Digest Footer
_______________________________________________
wp-hackers mailing list
http://lists.automattic.com/mailman/listinfo/wp-hackers
------------------------------
End of wp-hackers Digest, Vol 102, Issue 19
*******************************************