Skip to content


DBAL-921: [GH-616] Always store dates in UTC #2163

doctrinebot opened this Issue · 2 comments

2 participants


Jira issue originally created by user @doctrinebot:

This issue is created automatically through a Github pull request on behalf of LinusU:

Url: #616


This PQ will make sure that the dates saved in the database (without indication of timezone) is always stored in the UTC timezone.

I was doing development on my machine in Sweden when I noticed that when I created a DateTime, stored it in the db and then retrieved it again, the time was off by two hours. This is because a created the DateTime object with the UTC timezone. Doctrine then saved it straight to the database (by using $date->format(...)) and thus the information about which timezone it was in was lost. When doctrine then fetched the value, it used DateTime::createFromFormat(...) to create a DateTime for me. The problem is that since the timezone wasn't saved anywhere, it assumed that it was a Swedish date, and thus it removed two hours.

I believe that the correct way of doing it is to store the dates in the db as UTC. Then it will always work no matter what the default timezone is, even if I later decide to change it.

date*default_timezone*set('UTC') is not the answer. If I use it, I need to make sure that every DateTime that I pass to doctrine always has the timezone set to UTC. Since the DateTime can come from any number of sources (e.g. third party library) it could easily introduce hard to detect bugs. It will also output every date in the UTC timezone which may not be what I want if I'm developing a localised site (e.g. small page for a local Swedish business).


Comment created by @doctrinebot:

A related Github Pull-Request [GH-616] was closed:


Issue was closed with resolution "Won't Fix"

@doctrinebot doctrinebot added the Bug label
@beberlei beberlei was assigned by doctrinebot
@doctrinebot doctrinebot closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.