#perl #datetime #catalyst #dbix-class
#perl #datetime #катализатор #dbix-класс
Вопрос:
У меня возникли проблемы при сравнении объектов DateTime в моем катализаторе. У меня есть столбец end_date, который раздувается DBIx::Class::InflateColumn::DateTime, и я раздуваю его своим часовым поясом:
__PACKAGE__->add_columns(
end_date => { data_type => 'datetime', time_zone => 'America/Chicago' },
);
У меня есть функция, которая должна сообщать мне, закрылось ли мое событие или нет, это определено в моей схеме для этого класса:
sub closed {
my ($self) = @_;
my $now = DateTime->now(time_zone => 'America/Chicago');
warn DateTime->compare($now, $self->end_date);
warn $now;
warn $self->end_date;
return DateTime->compare($now, $self->end_date) == 1;
}
Однако он не работает должным образом. Это говорит мне, что события закрылись до того, как они действительно произошли. Вот пример вывода из предупреждений:
1
2014-06-29T12:20:48
2014-06-29T12:20:50
Как вы можете видеть, это говорит о том, что первая дата больше, чем end_date, хотя это не так. Я не смог понять, почему это так. Однако всякий раз, когда я конвертирую их и создаю новые объекты DateTime:
sub closed {
my ($self) = @_;
my $now = DateTime::Format::ISO8601->parse_datetime(DateTime->now(time_zone => 'America/Chicago'));
my $end_date = DateTime::Format::ISO8601->parse_datetime($self->end_date);
return DateTime->compare($now, $end_date) == 1;
}
Затем они сравниваются правильно, и сравнение возвращает -1. Кто-нибудь знает, почему это может быть?
Ответ №1:
Ваша отладочная информация бесполезна, поскольку вы не включили смещения часовых поясов (например, с помощью ->strftime('%FT%T%z')
). Если вы это сделали, бьюсь об заклад, вы обнаружите, что первая дата действительно больше конечной даты, и я уверен, что для вашего раздутого столбца используется UTC.
Глядя на документы, часовой пояс должен быть указан timezone
атрибутом, но вы использовали time_zone
.
{ data_type => 'datetime', timezone => "America/Chicago", locale => "de_DE" }
(Это был плохой, запутанный выбор от имени D :: C ::IC::DT.)
Комментарии:
1. Спасибо. Вы были правы, он не раздувался до того же часового пояса. Поэтому, когда я сохраняю его в базе данных, именно мои настройки базы данных будут определять часовой пояс для строки, такой как
2014-06-29 12:20:48
, не так ли? Потому что теперь, когда он преобразуется, он фактически преобразуется в неправильное время для моего текущего часового пояса.