Timezone handling for DateTime arguments for queries #5976

New Issue

admin · 2026-01-22T15:23:51+01:00

admin commented

2026-01-22 15:23:51 +01:00

Originally created by @stof on GitHub (May 30, 2018).

Feature Request

Q	A
New Feature	no
RFC	yes
BC Break	maybe in some cases

Summary

Currently, the type of a parameter with a DateTimeInterface value gets guessed as being datetime. In case the DB field is a datetimetz and the default timezone of the server does not match the timezone of your DateTime object, this might create some issues.

My proposal is to change the guessing to use the full precision of the value, by guessing it as datetimetz.

Here is my evaluation of the impact:

no impact for the UnitOfWork persistence, as it does not rely on guessing but passes types explicitly based on the mapping. the impact will be only for custom queries.
no impact for platforms not supporting datetimetz (MySQL for instance), as DBAL silently treats it as datetime internally anyway (and so the behavior would be the same than today)
potential BC breaks for code using a datetime field in their mapping on a platform supporting datetimetz, because the argument passed to the DB would now use the timezone of the argument (and convert it to the DB timezone) instead of assuming that the argument was already in the timezone of the DB. If your PHP server and your DB server already use the same default timezone, you are safe (unless you create objects in a non-default timezone and pass them directly to the DB without converting them, and expecting that no timezone conversion happens). If you have different default timezones, weird things might happen (as Doctrine creates the DateTime objects in the default PHP timezone when reading the datetime field as it does not know the DB timezone)
impact for code using a datetimetz field on a platform supporting them: timezones are now handled properly.

I think this is important, as all best practices I saw in the postgresql ecosystem were saying "store the timestamp with timezone", precisely to avoid issues where the DB server and the application server have to agree on the timezone otherwise.

If we want to reduce the impact for people using datetime, we could imagine having a configuration setting to choose what the default datetime handling should be (datetimetz or datetime) depending on their project needs.

Originally created by @stof on GitHub (May 30, 2018). ### Feature Request  | Q | A |------------ | ------ | New Feature | no | RFC | yes | BC Break | maybe in some cases #### Summary Currently, the type of a parameter with a DateTimeInterface value gets guessed as being `datetime`. In case the DB field is a datetimetz and the default timezone of the server does not match the timezone of your DateTime object, this might create some issues. My proposal is to change the guessing to use the full precision of the value, by guessing it as `datetimetz`. Here is my evaluation of the impact: - no impact for the UnitOfWork persistence, as it does not rely on guessing but passes types explicitly based on the mapping. the impact will be only for custom queries. - no impact for platforms not supporting `datetimetz` (MySQL for instance), as DBAL silently treats it as `datetime` internally anyway (and so the behavior would be the same than today) - potential BC breaks for code using a `datetime` field in their mapping on a platform supporting `datetimetz`, because the argument passed to the DB would now use the timezone of the argument (and convert it to the DB timezone) instead of assuming that the argument was already in the timezone of the DB. If your PHP server and your DB server already use the same default timezone, you are safe (unless you create objects in a non-default timezone and pass them directly to the DB without converting them, and expecting that no timezone conversion happens). If you have different default timezones, weird things might happen (as Doctrine creates the DateTime objects in the default PHP timezone when reading the datetime field as it does not know the DB timezone) - impact for code using a `datetimetz` field on a platform supporting them: timezones are now handled properly. I think this is important, as all best practices I saw in the postgresql ecosystem were saying "store the timestamp with timezone", precisely to avoid issues where the DB server and the application server have to *agree* on the timezone otherwise. If we want to reduce the impact for people using `datetime`, we could imagine having a configuration setting to choose what the default datetime handling should be (`datetimetz` or `datetime`) depending on their project needs.

admin commented

2026-01-22 15:23:51 +01:00

@goetas commented on GitHub (May 6, 2019):

PostgreSQL officially discourages the use of timestamp without time zone when storing timestamps (the PHP Datetime object). See https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_timestamp_.28without_time_zone.29 that gives some very good reasons for it.

So if is for 3.0 I'm totally for this change!

@goetas commented on GitHub (May 6, 2019): PostgreSQL officially discourages the use of timestamp without time zone when storing timestamps (the PHP Datetime object). See https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_timestamp_.28without_time_zone.29 that gives some very good reasons for it. So if is for 3.0 I'm totally for this change!

admin commented

2026-01-22 15:23:53 +01:00

@itinance commented on GitHub (Nov 10, 2023):

any news on this?

@itinance commented on GitHub (Nov 10, 2023): any news on this?

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5976