DDC-657: DateTime objects casted to string in query results #808

New Issue

admin · 2026-01-22T12:51:14+01:00

admin commented

2026-01-22 12:51:14 +01:00

Originally created by @doctrinebot on GitHub (Jun 27, 2010).

Jira issue originally created by user zyxist:

As we read in the documentation, 'datetime' fields are casted by Doctrine to PHP DateTime class objects. However, when we want to get only certain fields from a table using DQL, Doctrine casts the datetime value to ordinary string. Consider the following example:

/****
 * @var DateTime $active
 *
 * @Column(name="registered", type="datetime")
 */
private $registered;

var_dump($em->createQuery('SELECT u.id, u.registered FROM Entities\\User u')->getResult());

Expected result:

The returned row contains DateTime object for 'registered' column.

Actual result:

The returned row contains string for 'registered' column.

If this is an intended feature, first of all, it should be clearly pointed in the documentation that Doctrine types do not apply in such situations, and secondly, I think it is a very bad practice. I use Doctrine and tell him I have a datetime field in order to get Datetime objects automatically, not to deal with manual conversions.

Originally created by @doctrinebot on GitHub (Jun 27, 2010). Jira issue originally created by user zyxist: As we read in the documentation, 'datetime' fields are casted by Doctrine to PHP DateTime class objects. However, when we want to get only certain fields from a table using DQL, Doctrine casts the datetime value to ordinary string. Consider the following example: ``` /**** * @var DateTime $active * * @Column(name="registered", type="datetime") */ private $registered; ``` ``` var_dump($em->createQuery('SELECT u.id, u.registered FROM Entities\\User u')->getResult()); ``` Expected result: - The returned row contains DateTime object for 'registered' column. Actual result: - The returned row contains string for 'registered' column. If this is an intended feature, first of all, it should be clearly pointed in the documentation that Doctrine types do not apply in such situations, and secondly, I think it is a very bad practice. I use Doctrine and tell him I have a datetime field in order to get Datetime objects automatically, not to deal with manual conversions.

admin added the New Feature label 2026-01-22 12:51:14 +01:00

admin closed this issue

2026-01-22 12:51:14 +01:00

admin commented

2026-01-22 12:51:14 +01:00

@doctrinebot commented on GitHub (Jun 27, 2010):

Comment created by @beberlei:

oh wait, i am just now looking at your query, you are retrieving the values as scalar fields, that is something totally different. Let me check the code on this issue.

@doctrinebot commented on GitHub (Jun 27, 2010): Comment created by @beberlei: oh wait, i am just now looking at your query, you are retrieving the values as scalar fields, that is something totally different. Let me check the code on this issue.

admin commented

2026-01-22 12:51:16 +01:00

@doctrinebot commented on GitHub (Jun 27, 2010):

Comment created by zyxist:

ORM - the newest one from Git. I couldn't find any matching version in the issue form, so I selected nothing.
DBAL - the version that currently works with ORM. I've already noticed that DBAL-master does not work with the newest ORM :).

@doctrinebot commented on GitHub (Jun 27, 2010): Comment created by zyxist: ORM - the newest one from Git. I couldn't find any matching version in the issue form, so I selected nothing. DBAL - the version that currently works with ORM. I've already noticed that DBAL-master does not work with the newest ORM :).

admin commented

2026-01-22 12:51:17 +01:00

@doctrinebot commented on GitHub (Jun 27, 2010):

Comment created by @beberlei:

Ok the problem is that currently scalar values retrieved from a DQL query are not converted to their PHP value. This affects scalar values only, if you rewrite the query to:

SELECT u FROM Entities\User u

you will get the Entities\User class with a DateTime instance in the "registered" variable.

@doctrinebot commented on GitHub (Jun 27, 2010): Comment created by @beberlei: Ok the problem is that currently scalar values retrieved from a DQL query are not converted to their PHP value. This affects scalar values only, if you rewrite the query to: ``` SELECT u FROM Entities\User u ``` you will get the Entities\User class with a DateTime instance in the "registered" variable.

admin commented

2026-01-22 12:51:18 +01:00

@doctrinebot commented on GitHub (Jun 28, 2010):

Comment created by zyxist:

So far, I simply added a manual conversion that checks if the object was returned or not, so it will still work once the bug is fixed. In my case, sometimes I prefer to retrieve certain columns only, because the entire row can be quite big.

@doctrinebot commented on GitHub (Jun 28, 2010): Comment created by zyxist: So far, I simply added a manual conversion that checks if the object was returned or not, so it will still work once the bug is fixed. In my case, sometimes I prefer to retrieve certain columns only, because the entire row can be quite big.

admin commented

2026-01-22 12:51:18 +01:00

@doctrinebot commented on GitHub (Jul 1, 2010):

Comment created by @beberlei:

I think we should really fix this using an additional bit of information on the ResultSetMapping to hint the hydrators which type a scalar value is, if its an entity field, otherwise do nothing in conversion.

Array or Object fields, or even complex objects and serialization structs are pretty useless otherewise :)

@doctrinebot commented on GitHub (Jul 1, 2010): Comment created by @beberlei: I think we should really fix this using an additional bit of information on the ResultSetMapping to hint the hydrators which type a scalar value is, if its an entity field, otherwise do nothing in conversion. Array or Object fields, or even complex objects and serialization structs are pretty useless otherewise :)

admin commented

2026-01-22 12:51:20 +01:00

@doctrinebot commented on GitHub (Aug 7, 2010):

Comment created by romanb:

Scheduled for 2.1 for now.

@doctrinebot commented on GitHub (Aug 7, 2010): Comment created by romanb: Scheduled for 2.1 for now.

admin commented

2026-01-22 12:51:20 +01:00

@doctrinebot commented on GitHub (Sep 15, 2010):

Comment created by @beberlei:

Convert to feature (from bug)

@doctrinebot commented on GitHub (Sep 15, 2010): Comment created by @beberlei: Convert to feature (from bug)

admin commented

2026-01-22 12:51:20 +01:00

@doctrinebot commented on GitHub (May 24, 2011):

Comment created by javol:

I'm observing this problem on ORM 2.0.3 package with MySQL database and I would really expect this conversion to be implicit.
The Docs (12.7.1. Query Result Formats) says:

Query#getArrayResult(): Retrieves an array graph (a nested array) that is largely interchangeable with the object graph generated by Query#getResult() for read-only purposes.

But it is not interchangeable at all.

Anyway: It can potentially be an issue when dealing with timezones as the as it exposes the date in it's original format stored in DB, eventually without timezone on most DB engines. To interpret the such date the same way as Doctrine when hydrating to Object, one would need to know what timezone uses doctrine to interpret the DB timestamps without timezone.

@doctrinebot commented on GitHub (May 24, 2011): Comment created by javol: I'm observing this problem on ORM 2.0.3 package with MySQL database and I would really expect this conversion to be implicit. The Docs (12.7.1. Query Result Formats) says: <cite>Query#getArrayResult(): Retrieves an array graph (a nested array) that is largely interchangeable with the object graph generated by Query#getResult() for read-only purposes.</cite> But it is not interchangeable at all. Anyway: It can potentially be an issue when dealing with timezones as the as it exposes the date in it's original format stored in DB, eventually without timezone on most DB engines. To interpret the such date the same way as Doctrine when hydrating to Object, one would need to know what timezone uses doctrine to interpret the DB timestamps without timezone.

admin commented

2026-01-22 12:51:20 +01:00

@doctrinebot commented on GitHub (Jan 13, 2012):

Comment created by @guilhermeblanco:

We have a nearly done PR for this issue: https://github.com/doctrine/doctrine2/pull/251
As soon as Fabio changes the pointed optimizations, this issue will be closed.

@doctrinebot commented on GitHub (Jan 13, 2012): Comment created by @guilhermeblanco: We have a nearly done PR for this issue: https://github.com/doctrine/doctrine2/pull/251 As soon as Fabio changes the pointed optimizations, this issue will be closed.

admin commented

2026-01-22 12:51:22 +01:00

@doctrinebot commented on GitHub (Jan 14, 2012):

Comment created by @FabioBatSilva:

Fixed since this commit : ea14bcff4a

@doctrinebot commented on GitHub (Jan 14, 2012): Comment created by @FabioBatSilva: Fixed since this commit : https://github.com/doctrine/doctrine2/commit/ea14bcff4a2a78bf774e8847b6645dca112f9757

admin commented

2026-01-22 12:51:22 +01:00

@doctrinebot commented on GitHub (Jan 14, 2012):

Issue was closed with resolution "Fixed"

@doctrinebot commented on GitHub (Jan 14, 2012): Issue was closed with resolution "Fixed"

admin referenced this issue

2026-01-22 16:01:28 +01:00

[PR #808] [MERGED] Second level cache #8739

Sign in to join this conversation.