[wp-hackers] Date/Time and WP

[Dobri]

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

On Wed, 17 Jul 2013, at 9:18 AM, Ryan McCue wrote:

> Dobri wrote:
>> 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/>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers