Comments on: Handling timezone conversion with PHP DateTime

By: Nick

Nick — Sat, 21 Jan 2012 12:34:51 +0000

Thanks for this

By: Vibha

Vibha — Wed, 19 Oct 2011 09:19:03 +0000

Hi,

Thanx for the script,

I am showing server time and client time both on a page, used different variables. Script works fine in Firefox and Chrome, but in Safari, IE9 and Opera, it is not working, either or both times are not showing.
Please help

By: Gary

Gary — Mon, 02 May 2011 01:12:49 +0000

Thanks for this. I found the information and technique very useful.

By: Richard Williams

Richard Williams — Tue, 19 Apr 2011 18:11:19 +0000

This worked fine for me.

Thanks for a good tutorial, pointed me in the right direction after going mad with bugs in PEAR Date.

I’ve written up a simple function based on Josh’s script…

http://richardwillia.ms/blog/2011/04/time-zone-conversion-using-datetime-class/

By: arpatech

arpatech — Mon, 28 Mar 2011 17:15:21 +0000

works for me.

setTimezone(new DateTimeZone(‘Asia/Manila’));
echo $myDateTime->format(‘Y-m-d H:i’);
?>

By: Jeff

Jeff — Sat, 12 Feb 2011 03:02:34 +0000

I see a lot of people have already commented more or less what I was going to say — it’s much easier to use the setTimezone() method. However I’d like to point out that it’s not only easier, it’s really the way you have to do it (if you want it to work). First off, the approach your suggesting only appears to work because you happen to be calculating your offset against a DateTime object which happens to be using the GMT timezone. getOffset() always returns the offset from GMT, regardless of the timezone set on the DateTime object you use. In fact, the only reason you need the DateTime object is because that world time is used to determine what the offset is — The offset changes for TimeZones which follow daylight savings time and depending on what time of the year it is, the offset will change.
Mostly I want to point out though that your method of changing the time using the offset will leave you with a new DateTime object that has the wrong time. Or rather it will have the right time, but the wrong TimeZone. Worse it won’t necessarily be the right time — if you happen to offset the time across a clock change (spring forward, fall back) you’ll end up with the wrong time and the wrong timezone.
Here’s what I’m getting at. Suppose the following time
date_create(’2011-03-13T01:30′, timezone_open(‘America/Chicago’));
That’s just 30 minutes before the clocks get turned forward. If you add an hour with the following line
$sometime->add(date_interval_create_from_date_string(’1 hour’));
The resulting time is actually 3:30am because the hour from 2-3am doesn’t exist. Also, the clocks in the US all change at 2am based on local time, so strangely enough, in the fall you end up with a situation where 2:30am in Chicago is actually the second 2:30am in New York.
If you use the setTimezone method though you’ll find that your times always change consistently because under the covers they’re always tracking UTC (GMT).

By: James

James — Tue, 07 Dec 2010 14:57:03 +0000

Very useful, thanks, just put Timezone handling into our open source project :-)

By: Skibbler Elf

Skibbler Elf — Sat, 30 Oct 2010 04:12:15 +0000

This post has helped a ton. It does help to know your user’s timezone…then you can figure the offset and store the correct time (most likely UTC) in your dB.

Ciao

By: GMTSlider.com

GMTSlider.com — Tue, 28 Sep 2010 12:21:03 +0000

That’s exactly the code i was looking for so long! Thanks!

By: Automatic timezone conversion with JavaScript « Boxed Ice Blog

Automatic timezone conversion with JavaScript « Boxed Ice Blog — Fri, 03 Sep 2010 09:58:55 +0000

[...] 3, 2010 tags: dates, javascript, jquery, js, timezones by David Mytton Timezones are a pain to deal with as a programmer but our server monitoring service, Server Density, has handled them for some time. It requires you [...]