[NFR] Datetime column type

[SliceOfLife]

What about adding "datetime" column type for Model? By default the "@var \Datetime" converted to string.

[niden]

@SliceOfLife I am not sure I understand what you mean. Could you please explain with an example what you are trying to do ?

[SliceOfLife]

For example, I have a Mysql DB and table with datetime column. I want to write the Model class with \DateTime field:

class SomeModel extends \Phalcon\Mvc\Model 
{
    /**
     * @Column(type="datetime", nullable=false)
     *
     * @var \DateTime
     */
    public $datetime_field;

    public function initialize()
    {
        $this->datetime_field = new \DateTime();
    }
}

But I can't use the "datetime" column type, it's very sad. This code throws error like "Object of class DateTime�����w could not be converted to string".

[niden]

Hmmm for some reason my comment disappeared.

Either way.

This is not a blocker and the desired functionality can be achieved with a minor change in the code. We can add it as a NFR but it will take a low priority one and we also need to test the impact that this will have on the framework as far as performance is concerned.

You can achieve what you need with:

$now = new \DateTime();
$this->datetime_field = $now->format('Y-m-d H:i:s');

or without using datetime

$this->datetime_field = date('Y-m-d H:i:s');

[SliceOfLife]

It will be a cool feature. By the way, I use an integer timestamp and Mysql INT(11) type for now.

[niden]

I follow the same practice too (using integers). Much faster to search/index, you can perform easy math operations with them (to find differences etc.) and for me at least it is a lot more logical. You also escape the different formatting conventions i.e. m/d/y, y.m.d etc.

[niden]

@dalu I haven't personally used a 32bit machine in a few years and are seeing them disappear. However, the easy solution on that would be again numeric fields. You will just need to have two per date (if you want to store hours/minutes/seconds)

For the date I would store this:

20130414 (which is 2013-04-14)

and for the time the same thing

175432 (which is 17:54:32)

This way you have no issues with 32 bit machines. :)

Having said that, with the way technology is going, I doubt we will have any 32bit machines by that year.

[niden]

Closing this as we will not be implementing automatic Datetime fields in Phalcon in the very near future. Perhaps in 2.0+

[lfbittencourt]

+1 for this!

[tmihalik]

+1

[AndreBaumeier]

+1

[loopsframework]

+1 I would welcome it if Phalcon translates the DateTime object to the format expected by the database backend. With this layer of abstraction, code should become more portable.

[f3l1x]

:+1:

[sergeyklay]

@niden

Closing this as we will not be implementing automatic Datetime fields in Phalcon in the very near future. Perhaps in 2.0+

Now is 2.0+ :)

[MLukman]

I vote for this feature implemented about now.

[StudioMaX]

+1

[reloaded]

+1

[efimBistrov]

+1

[kornerita]

Hi,

I've found this thread and I would like to add the following:

• Regarding the performance impact, there is already a "castOnHydrate" option to disable if you don't need it or if you want performance (by default it comes disabled).
• For this implementation there should be methods on the Phalcon\Db\Dialect to establish the default date format returned by the engine for each date type (i.e. date or timestamp) and methods to transform the result from those to a \DateTime object. Note: I think here is the actual casting.

My personal opinion about this, is that an ORM should abstract you on the date format the database engine is using and should use native language date manipulations. This adds transparency when you want or need to change a database engine.

Regards, Federico.

[stale[bot]]

Thank you for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please feel free to either reopen this issue or open a new one. We will be more than happy to look at it again! You can read more here: https://blog.phalconphp.com/post/github-closing-old-issues

[StudioMaX]

This is still relevant.

[niden]

https://github.com/phalcon/cphalcon/pull/13562