stsc / DateTime-Format-Natural

Parse informal natural language date/time strings
5 stars 5 forks source link

'floating' TZ seems to produce incorrect results [rt.cpan.org #53983] #12

Open stsc opened 3 years ago

stsc commented 3 years ago

Migrated from rt.cpan.org#53983 (status was 'open')

Requestors:

From kev@brantaero.com on 2010-01-25 20:13:36 :

Using the constructor with no parameters and then parse_datetime() on
'3pm' and 'now' gives two different values, even though it is currently
3pm.  '3pm' returns 10am, whereas 'now' gives the correct value.

If I get the date from gmtime and pass the components to DateTime and
pass that to the constructor, I get the same thing.  If I use localtime
instead, both 'now' and '3pm' return 10am.

I would just use the proper time zone, but since I'm parsing AJAX user
input, this means someone entering 9002 instead of 2009 will bring the
server to its knees trying to calculate DST offsets (as DateTime's docs
mention.)

From schubiger@cpan.org on 2010-09-30 14:06:03 :

On Mon Jan 25 15:13:36 2010, Kevin_Field wrote:
> I would just use the proper time zone, but since I'm parsing AJAX user
> input, this means someone entering 9002 instead of 2009 will bring the
> server to its knees trying to calculate DST offsets (as DateTime's docs
> mention.)

Understandable.  Do you have a concrete idea or suggestion how to
circumvent this limitation?

From kev@brantaero.com on 2010-09-30 14:13:11 :

On Thu Sep 30 10:06:03 2010, SCHUBIGER wrote:
> On Mon Jan 25 15:13:36 2010, Kevin_Field wrote:
> > I would just use the proper time zone, but since I'm parsing AJAX user
> > input, this means someone entering 9002 instead of 2009 will bring the
> > server to its knees trying to calculate DST offsets (as DateTime's docs
> > mention.)
> 
> Understandable.  Do you have a concrete idea or suggestion how to
> circumvent this limitation?

It's not this limitation (9002 vs 2009) that I'm complaining about, I
just mentioned it because I expected it would be the suggested
workaround.  I think it's a bug that if you call with no parameters and
parse the current time (e.g. 3pm) it returns a different time.  "No time
zone" should mean no shift, not a hidden conversion to GMT.  Beyond that
I'm not sure how to fix it--I haven't looked at this code in months to
be honest.  Thanks for responding though.

Kev