ZF-1978: Add $_(date|time|datetime)Format private properties to Zend_Db_Adapters, let the query methods accept parameters of type Zend_Date

Issue Type: Improvement Created: 2007-09-21T14:33:12.000+0000 Last Updated: 2012-05-06T15:16:57.000+0000 Status: Closed Fix version(s): Reporter: Tobias Gies (ruunstalker) Assignee: Adam Lundrigan (adamlundrigan) Tags: - Zend_Db

  • zf-crteam-review

Related issues: - ZF-3072



Followup to the ML discussion located HERE

  • All Zend_Db_Adapters should get new private properties named $_dateFormat, $_timeFormat and $_datetimeFormat. These properties should contain Zend_Date formatstrings for dates, times and datetime values appropriate for the respective database types.
  • All methods of Zend_Db_Adapters, Zend_Db_Table and Zend_Db_Select that handle parameter binding (such as, but not only, the Zend_Db_Adapter_Abstract::quote_() and Zend_Db_Adapter_Abstract::fetch_() families and the Zend_Db_Select::where() and having() methods, as well as the Zend_Db_Table magic setter methods) should be made capable of turning a given Zend_Date object into a date, time or datetime value appropriate to the respective database type.
  • There should be methods named get(Date|Time|DateTime)Format() to enable the user to get the Zend_Date formatstring that is stored in the Zend_Db_Adapter.
  • Setter-methods for these private properties should be explicitly prohibited.

The target of this improvement is to enhance the usability and interoperability of Zend_Date with databases, so that the user does not have to care about the right datetime value format for the database he/she is using. Also, through the formatstring getter-methods, the user should get an easy way to turn a column value which he/she knows is a datetime value back into a Zend_Date object. Setting these formatstrings must, of course, not be possible because they are database specific, and setting them to different values may lead to unexpected and unforeseeable results.


Posted by Thomas Weidner (thomas) on 2007-09-21T15:08:14.000+0000

As this is database specific it would be best that each adapter know what date/time format he wants to have.

The handling within Zend_Date is quite easy...

<pre class="highlight">
$date = new Zend_Date($format, $dbformat);
$databasevalue = $date->toString($dbformat);

But also to mention... The fastest way would be to have all dates extracted as unix timestamp from the database... Each database also accepts timestamps as input for datetime fields. This would mean that no parsing has to occur which would make the code much faster.

Posted by Stephen Crosby (stevecrozz) on 2007-09-24T14:44:44.000+0000

Additionally, it would be very handy to allow Zend_Db to automatically adjust incoming and outgoing Zend_Date objects for database-specific date object fields, and also automatically adjust them to GMT and back.

Posted by Darby Felton (darby) on 2007-09-26T14:56:24.000+0000

Assigning to [~bkarwin] to initiate issue review.

Posted by Artur Jedlinski (nataniel) on 2007-09-28T01:02:36.000+0000

Thomas said: "Each database also accepts timestamps as input for datetime fields." You have to rememer that timestamp to date conversion rely on the timezone of database. If I'm going to use different timezone that the server is set to and I want to keep dates in that timezone in my DB - I cannot use db timestamp conversion. Of course if I don't care what's inside the tables, I can use server timezone for all conversions, but that's inconvient if I would like to view/edit the data using some external app like phpMyAdmin - I need to remember the timezone.

Posted by Artur Jedlinski (nataniel) on 2007-09-28T02:07:19.000+0000

It would be also great to have a method to easily create Zend_Date objects from the database field, like:

<pre class="highlight">

Then the Zend_Db_Adapter_Abstract would have:

Posted by Thomas Weidner (thomas) on 2008-03-11T03:33:23.000+0000

Class will be reworked by Simon... sorry if I confused anybody. He has a better overview over the complete Db design, not only Zend_Db_Select and will help better than me.

Posted by Wil Sinclair (wil) on 2008-03-25T20:43:57.000+0000

Please categorize/fix as needed.

Posted by Wil Sinclair (wil) on 2008-03-25T22:06:45.000+0000

Resetting 'fix version priority' and 'fix version' to be re-evaluated for next release.

Posted by Wil Sinclair (wil) on 2009-01-06T14:35:05.000+0000

This issue has gone unaddressed for too long. I'm re-assigning to Ralph for re-evaluation and categorization.

Posted by Tobias Gies (tobias) on 2009-04-30T13:02:05.000+0000

I think this is out of scope for a normal issue and needs to be addressed in its own proposal. If others agree, I will try to get a proposal started instead, and will close this issue.

Posted by Thomas Weidner (thomas) on 2009-04-30T13:14:02.000+0000

Issues should not be closed for a proposal.

You should add a proposal, link from the proposal to the issue as reference. And additionally add a comment to the issue with a link to the proposal.

The issue itself should be closed as soon as your proposal is completly finished and ready for core. Issues are better searchable and people tend first to look at issues than at proposals. This hsa also the effect that your proposal will be more reviewed as people finding this issue will also look at your proposal.

Posted by Thomas Deutschmann (whissi) on 2010-07-01T11:48:55.000+0000

What's the current status of this issue? It started in 2007 but it is still open. Did I miss something?

Will it be addressed in 2.0?

Posted by Ralph Schindler (ralph) on 2010-07-09T08:22:53.000+0000

Yes, this is something that will be addressed in 2.0. More aptly described as a way to cast between datatypes. Keep an eye out here:…


Posted by Adam Lundrigan (adamlundrigan) on 2011-11-17T02:19:14.000+0000

Can this issue be closed and/or shifted to ZF2 JIRA project? or are there plans to implement it in ZFv1?

Posted by Adam Lundrigan (adamlundrigan) on 2012-05-06T15:16:56.000+0000

Closing as "Won't Fix" for ZFv1. Please reopen if this is incorrect.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.