Skip Menu |

This queue is for tickets about the DateTime-Format-Natural CPAN distribution.

Report information
The Basics
Id: 53983
Status: open
Priority: 0/
Queue: DateTime-Format-Natural
People
Owner: Nobody in particular
Requestors: kev [...] brantaero.com
Cc:
AdminCc:
Bug Information
Severity: Important
Broken in: 0.83
Fixed in: (no value)

History Show all quoted text
  Mon Jan 25 15:13:36 2010 kev [...] brantaero.com - Ticket created
Subject: 'floating' TZ seems to produce incorrect results
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.)
  Thu Sep 30 10:06:03 2010 schubiger [...] cpan.org - Correspondence added
On Mon Jan 25 15:13:36 2010, Kevin_Field wrote: Show quoted text
> 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?
  Thu Sep 30 10:06:07 2010 The RT System itself - Status changed from 'new' to 'open'
  Thu Sep 30 10:13:11 2010 kev [...] brantaero.com - Correspondence added
From: kev [...] brantaero.com
On Thu Sep 30 10:06:03 2010, SCHUBIGER wrote: Show quoted text
> 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