PHP DateTime vs mktime / strtotime in Propel

One of the relatively new features in PHP 5.2, is the DateTime class/functions. It has a few useful functions (date_parse, date_date_set, date_time_set etc) which make dealing with dates and times easier (date_parse provides some useful error info too).

Unfortunately, the PHP api still doesn't allow for something like :


$seconds = $dateTime->parse($string, $format);

Where $format would be something like : "d/m/y H:i:s".

Instead it sticks to the strtotime convention, which is a pain for those of us who don't live in the US and have customers who want to see dates in a dd/mm/yyyy format in input fields, but I digress.

One other good thing about DateTime is that it does at least allow you to store dates before 1970 or after 2038, which became useful recently with how we were/are using Propel.

Propel 1.2 stores dates within a model object as integer values, allowing you to specify a format to the date when calling the fields accessor method (e.g getDateCreated("d/m/Y")). Unfortunately it uses strtotime, which for some reason doesn't like dates before 1970 on the Linux platforms we use, and just returns NULL or FALSE.

So, on Friday, we ended up modifying our version of Creole and Propel to store DateTime objects internally instead of integers. I think Propel 1.3 uses the DateTime 'stuff' (as well as PDO), but as it's still in 'beta' and it's API has changed, I've not yet moved to use it.

Technorati Tags:

Comments

If you're missing something...

add a feature request at bugs.php.net - it might get included in the next PHP version ;-)

feature request...

I guess I should.... thanks for the hint :)

php bug report...

Propel 1.3

It may say beta on the release name but it's far from buggy, I am using it in quite a few production sites. You should consider changing sometime soon as the final is not far away at this point in time, I am writing a debug layer for it that will give considerable profiling and debug information for each query ran and after that it will be one more beta then probably final straight after that...

PS: I'm a core propel developer

propel 1.3... is good.

I did try one of it's first beta releases a few months ago, and certainly noticed a possible doubling of speed (presumably thanks to PDO).... so I definitely will change eventually....

My immediate problem is that we've written a number of libraries around 1.2, which would require sometime to rewrite and test... it's not a big hurdle, but it's big enough to make me wait for it 1.3 to come out of beta first!

Logging in Propel 1.3

Will Propel 1.3 have better logging support, soon?

By your post here, I'm guessing it'll be more extensive, but that's not really enough.

I was looking at it yesterday.. (background: I'm working on a Propel 1.3 plugin for symfony). Someone mentioned to me that the debug toolbar was no longer displaying Propel debug. I looked at Doctrine, and they're using more of the 'event listener' approach. The only way to get what I wanted was to modify PropelPDO and add wrappers to functions that I wanted to log (and changed existing log calls to the format I wanted).

Ideally, there'd either be an event listener, or a way to extend PropelPDO (and thus tell Propel which class to instantiate when creating the PDO connection).

I tried creating a ticket on this yesterday, but the Propel Trac was telling that I was a spammer, so I haven't been able to bring it up at all..

DateTime - session issues

Of course, with how we use Propel, we often end up storing the propel generated objects in a user's session. Unfortunately, using the DateTime object as an object attribute type causes problems, as inbuilt PHP objects cannot be serialised.

Therefore, I've ended up having to store the date/time fields as strings within the object, and parsing them into date time objects before outputting them in which ever format is required.

Propel 1.3 seems to take the view of storing time/date fields as integers, in a date('U') format ... which isn't of much use for dates before the unix epoch (afaik).

Works now...

This is also addressed in PHp 5.3 - you can now happily serialize DateTime objects.

the conclusion ....

Just to conclude, PHP 5.3 has support for what I was after, namely see :

http://www.derickrethans.nl/british_date_format_parsing.php

bugs.php.net

Added some stuff there but no response as of yet. *sigh* why does PHP have to be so americanized haha

im kidding

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <img>
  • Lines and paragraphs break automatically.

More information about formatting options

CAPTCHA
We don't take kindly to automated nonsensible adverts around here.