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
Related issues: - ZF-3072
Followup to the ML discussion located HERE
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: http://framework.zend.com/wiki/display/…
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.