[phpns-dev] PHP DateTime Object

[Trevor Morse]

Hey Everyone,

Was just reading this article about the PHP DateTime Object
http://techportal.ibuildings.com/2010/04/29/tips-for-working-with-datetime-in-php/
and realized I have never used it.

I have always used date(), strtotime(), etc to handle all dates.
However it appears using the Object can help with timezone conversions
and make it much easier to work with dates, as well as storing the
serialized objects for later use.

Has anyone used this object yet? Any pros/cons/problems with it?

-tm

--
You received this message because you are subscribed to the Google Groups "Halifax, NS PHP Developers Group" group.
To post to this group, send email to halifax-ns-php-...@googlegroups.com.
To unsubscribe from this group, send email to halifax-ns-php-develo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/halifax-ns-php-developers-group?hl=en.

[David Wolfe]

DateTime is pretty good.  You'll still find you'll need to use your old tricks on occasion, but it's a very reasonable "core" representation for most purposes.  For a while we were using PEAR's class --- mainly because it predates DateTime --- but that is incredibly resource intensive, and doesn't dovetail well the PhP's functions.  DateTime is working much better for us.

David

[Trevor Morse]

On Wed, May 5, 2010 at 8:00 PM, David Wolfe <davidga...@gmail.com> wrote:
> DateTime is pretty good.  You'll still find you'll need to use your old
> tricks on occasion, but it's a very reasonable "core" representation for
> most purposes.  For a while we were using PEAR's class --- mainly because it
> predates DateTime --- but that is incredibly resource intensive, and doesn't
> dovetail well the PhP's functions.  DateTime is working much better for us.

Thanks for the info David! I'm definitely going to have to look into
this for my next project. I'll circle back here if I come across any
problems.

-tm

[D. Keith Casey, Jr.]

On May 5, 3:10 pm, Trevor Morse <trevor.mo...@gmail.com> wrote:
> I have always used date(), strtotime(), etc to handle all dates.
> However it appears using the Object can help with timezone conversions
> and make it much easier to work with dates, as well as storing the
> serialized objects for later use.
>
> Has anyone used this object yet? Any pros/cons/problems with it?

Are you picking on me about the Timezone stuffI wrote for the last
web2project release?;)

To be honest, timezone handling is *hard*. Every time I think I've
figured it out, I come up with one more use case (and Unit Test of
course) that breaks things again. I've explored using the DateTime
classes and although they are *fantastic*, some of the best
functionality is 5.3 only... since 5.3 has only been out 10.5 months,
I feel it's a little premature to have a dependency on it.

That said, what is the mix of people here? Who does entirely internal
development on internal servers? Who does stuff that gets deployed on
customers' servers? Who writes stuff for the general web world?

kc

[Trevor Morse]

On Tue, May 11, 2010 at 6:00 PM, D. Keith Casey, Jr.
<ke...@blueparabola.com> wrote:
> On May 5, 3:10 pm, Trevor Morse <trevor.mo...@gmail.com> wrote:
>> I have always used date(), strtotime(), etc to handle all dates.
>> However it appears using the Object can help with timezone conversions
>> and make it much easier to work with dates, as well as storing the
>> serialized objects for later use.
>>
>> Has anyone used this object yet? Any pros/cons/problems with it?
>
> Are you picking on me about the Timezone stuffI wrote for the last
> web2project release?;)

No! I kinda forgot about that actually till I posted this here, and
then went digging to see what/how you did it :D

>
> To be honest, timezone handling is *hard*. Every time I think I've
> figured it out, I come up with one more use case (and Unit Test of
> course) that breaks things again. I've explored using the DateTime
> classes and although they are *fantastic*, some of the best
> functionality is 5.3 only... since 5.3 has only been out 10.5 months,
> I feel it's a little premature to have a dependency on it.

Unit Tests++ ;-)
Would be so easy if everyone was running 5.3. What is missing from 5.2
that is in 5.3?

>
> That said, what is the mix of people here? Who does entirely internal
> development on internal servers? Who does stuff that gets deployed on
> customers' servers? Who writes stuff for the general web world?

I do the full gamut. Everything from internal client-server socket
based apps, to hosted Drupal installs, to Wordpress installed on
customer servers for work. In my "spare" time I work on web2project
and some other side projects for friends that run on generic hosting
providers. Some that are still running php 4 *shudder*.

-tm

[Trevor Morse]

Hi Everyone,

Thought I would follow up with some weirdness that I have found after
using the DateTime object a bit.

Consider the following code:

<?php
$date_time = new DateTime('2010-05-26 10:00:00', new
DateTimeZone('America/Los_Angeles'));
echo 'Before timezone conversion:' . PHP_EOL;
echo $date_time->format('U') . PHP_EOL;
echo $date_time->format('r') . PHP_EOL;
echo strtotime($date_time->format('Y-m-d H:i:s')) . PHP_EOL;

$date_time->setTimezone(new DateTimeZone('America/New_York'));
echo 'After timezone conversion:' . PHP_EOL;
echo $date_time->format('U') . PHP_EOL;
echo $date_time->format('r') . PHP_EOL;
echo strtotime($date_time->format('Y-m-d H:i:s')) . PHP_EOL;
?>

The format function takes any argument that the regular date()
function call will. So 'U' is seconds since unix epoch. I would expect
that the the two format('U') function calls would produce different
results since we have changed the timezone and the format('r')
reflects that. However this is not the case, they return the exact
same timestamp - 1274893200. This appears to convert whatever
datetime you have stored to your default timezone before returning the
timestamp. This really stumped me for a bit, so thought I would
mention it here.

I got around this by using the strtotime function on a format from
DateTime that did not include the timezone(difference from Greenwich
time). See last line before and after timezone conversion. Which seems
to work, but there must be a better way.

Do any of you with more DateTime experience know of a better way to
handle this with functions that work in PHP < 5.3?

Thanks,

tm

[David Wolfe]

It may be confusing, but it is logical.  Unix time is always from the perspective of Greenich, so the timezone changes are irrelevant.

When you call strtotime, you are not specifying a timezone, so that's assumed to be Greenish.  So the difference of 4*60*60 between your strtotime and your format->('U') is explained by the difference in time zones between Halifax and Greenich.

David

[Trevor Morse]

Thanks for the explanation! With that and a little more thought on my
side it does make perfect sense! It would be even more confusing if
the epoch was different per timezone. This also explains why when you
pass a timestamp to the DateTime constructor it ignores the timezone
you pass :-)

I have just *never* had to deal with timezones so never had to think about it.

I guess in my case it would make more sense to convert the date from
whatever timezone I am bringing it in from to the local servers time,
then store to database. Then convert back to appropriate timezone when
sending out. Rather then storing a unix timestamp.

Thanks Again,

tm

[D Keith Casey Jr]

Trevor Morse wrote:
> I guess in my case it would make more sense to convert the date from
> whatever timezone I am bringing it in from to the local servers time,
> then store to database. Then convert back to appropriate timezone when
> sending out. Rather then storing a unix timestamp.

I also considered this approach as I've been doing timezone stuff in
web2project. The problem is that you've now introduced a hidden
dependency. What happens when you.. rebuild the server? Move the
database to another server? The timezone files on the server change?
That's right, in order to get the datetime back properly, you need to
know the timezone of the server on which you originally saved it.

I quickly came to the conclusion that converting/storing to GMT seems to
be the most consistent and safest approach. And then when you retrieve
it, transform it to the timezone you need. Alternatively, you could
store the value in *any* timezone as long as you note which one(s) it
is, but it needs to be documented *somewhere*.

My 0.02,
keith

--
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
D. Keith Casey, Jr.
Chief Technology Officer
http://BlueParabola.com

[Trevor Morse]

On Wed, May 26, 2010 at 10:34 PM, D Keith Casey Jr
<ke...@blueparabola.com> wrote:
> Trevor Morse wrote:
>>
>> I guess in my case it would make more sense to convert the date from
>> whatever timezone I am bringing it in from to the local servers time,
>> then store to database. Then convert back to appropriate timezone when
>> sending out. Rather then storing a unix timestamp.
>
> I also considered this approach as I've been doing timezone stuff in
> web2project. The problem is that you've now introduced a hidden dependency.
> What happens when you.. rebuild the server? Move the database to another
> server? The timezone files on the server change? That's right, in order to
> get the datetime back properly, you need to know the timezone of the server
> on which you originally saved it.

Good point.

>
> I quickly came to the conclusion that converting/storing to GMT seems to be
> the most consistent and safest approach. And then when you retrieve it,
> transform it to the timezone you need. Alternatively, you could store the
> value in *any* timezone as long as you note which one(s) it is, but it needs
> to be documented *somewhere*.

All of our data goes out in Eastern(EST/EDT) as a standard and is
documented as such. So in this case I think I am ok. Though your point
above does make good sense if you don't have a standard, or it might
change.

-tm

>
> My 0.02,
> keith
>
> --
> =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=
> D. Keith Casey, Jr.
> Chief Technology Officer
> http://BlueParabola.com
>