| Subject: | [PATCH] Better timezone handling |
Hi Steven,
First, thanks for the quick response on the previous ticket.
SCHUBIGER++. :)
We use this module on a web app for parsing dates. Our users are from
all over the globe. Unfortunately, the floating timezone does not
adequately meet our needs. Here's an example of the importance of using
time zones while parsing:
use Test::MockTime 'set_fixed_time'; # fixed_time is in UTC
use DateTime::Format::Natural;
set_fixed_time("2007-11-18T23:59:59");
warn DateTime::Format::Natural->new->parse_datetime("sunday"); #
2007-11-18
set_fixed_time("2007-11-19T00:00:00");
warn DateTime::Format::Natural->new->parse_datetime("sunday"); #
2007-11-25
The difference of a second in the input caused the difference of a week
in the output. The floating time zone acts like UTC until you force it
to a particular time zone, but (until this is fixed) that can only
happen after parsing. The net effect is, if you're in, say, America/
New_York, then this week jump will occur at 7PM. If you're in New
Zealand, then it will happen around noon. This occurs with many (if not
all) of the relative input types.
Here's a patch that adds better time zone handling in
DateTime::Format::Natural. It adds tests for the same, but the tests
add a new dependency, Test::MockTime. I don't think I can use the
_set_datetime trick for properly testing this.
Thanks!
Shawn
| Subject: | time_zone.diff |
Message body is not shown because it is too large.