Доктрина Symfony3, работающая с часовыми поясами

Я только что перенес проект Symfony2.4 на Symfony3.0 и столкнулся со странной ситуацией.

Часовой пояс проекта по умолчанию — UTC, все хранится в виде временных меток UTC в базе данных MYSQL.

Я получаю запись с полем даты и времени с именем «checkOut», передаю ее в шаблон ветки:

<p>{{ dump(entity.checkOut) }}</p>
<p>{{ dump(entity.checkOut.getTimestamp()) }}</p>

И я получаю:

DateTime {#585 ▼
  +"date": "2016-09-17 10:46:00.000000"
  +"timezone_type": 3
  +"timezone": "UTC"
}
1474109160

что правильно.

Но мое приложение должно поддерживать пользователей из разных часовых поясов. Поэтому я сохраняю предпочтительный часовой пояс пользователей и использую прослушиватель событий, чтобы установить его.

date_default_timezone_set($this->token_storage->getToken()->getUser()->getTimezone());

После этого выводится та же запись:

DateTime {#585 ▼
  +"date": "2016-09-17 10:46:00.000000"
  +"timezone_type": 3
  +"timezone": "Asia/Jakarta"
}
1474083960

Это явно неправильно, так как метка времени теперь другая. Я ожидал бы этого:

DateTime {#585 ▼
  +"date": "2016-09-17 17:46:00.000000"
  +"timezone_type": 3
  +"timezone": "Asia/Jakarta"
}
1474109160

Раньше это нормально работало в sf2.4. Может ли кто-нибудь объяснить, в чем проблема и как я могу ее обойти?


person gtsouk    schedule 27.09.2016    source источник


Ответы (1)


Это потому, что вы меняете часовой пояс по умолчанию вашего сервера, а не изменяете часовой пояс рассматриваемого экземпляра DateTime. Один из моих питомцев ненавидит!

Я не знаком с веткой, но выполнение чего-то подобного даст вам ожидаемый результат: -

<p>{{ dump(entity.checkOut) }}</p>
<p>{{ dump(entity.checkOut.setTimeZone(new \DateTimeZone("Asia/Jakarta"))) }}</p>
<p>{{ dump(entity.checkOut.getTimestamp()) }}</p>
person vascowhite    schedule 27.09.2016
comment
Спасибо за ваш ответ. Это действительно решение, но мне потребуется обновить каждый шаблон на веб-сайте. Также бывают случаи, когда, например, мне нужно получить все записи определенного месяца, и в этих случаях я также должен учитывать часовой пояс пользователя. Изменение часового пояса по умолчанию очень удобно, потому что все рассчитывается с часовым поясом пользователя. - person gtsouk; 27.09.2016
comment
Удобно да, но все же неправильно, как вы переживаете. - person vascowhite; 28.09.2016