Skip Menu |

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

Report information
The Basics
Id: 34336
Status: resolved
Priority: 0/
Queue: DateTime-Format-Natural

People
Owner: Nobody in particular
Requestors: diz [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in:
  • 0.50
  • 0.51
  • 0.52
  • 0.53
  • 0.54
  • 0.55
  • 0.56
  • 0.57
  • 0.58
  • 0.59
  • 0.60
  • 0.62
  • 0.63
  • 0.64
  • 0.65
  • 0.66
  • 0.67
  • 0.68
  • 0.69
Fixed in: 0.36



Subject: 0.50+ can't parse date that 0.36 could
apache emits Last-Modified headers in the following format: Mon, 10 Mar 2008 15:49:38 GMT DateTime::Format::Natural used to have no problem parsing that in v0.36. on our newest webserver, running 0.69, it no longer parses to the correct date. instead, it parses to the current date and time. i've got a production webserver that i've had to remove from our load balancer because of the incompatibility. i've looked briefly at the code, but i'm afraid i do not have any time within the next week to spend on finding a fix. also, i've noticed that you've removed all pre-0.50 releases from your directory. was that neccessary?
On Fri Mar 21 18:40:10 2008, DIZ wrote: Show quoted text
> apache emits Last-Modified headers in the following format: > Mon, 10 Mar 2008 15:49:38 GMT > > DateTime::Format::Natural used to have no problem parsing that in v0.36. > on our newest webserver, running 0.69, it no longer parses to the > correct date. instead, it parses to the current date and time.
Yes, this is correct. The current date/time is being returned, because no suitable token pair was found. Which actually means that the Datetime object never got modified in any way and hence, has been unmodified returned after examining the grammar table. As for no longer parsing the Apache headers: everything until release 0.50 was frankly a hack. Broken-by-design. As of version 0.50, there's a proper grammar and dispatch table, and as you already noticed, it no longer parses your input (I never designed it for parsing "arbitrary" strings, it just happened to be a fortunate coincidence in your case). Show quoted text
> i've got a production webserver that i've had to remove from our load > balancer because of the incompatibility.
Sorry for the inconvenience, but the fundamental changes had to be. Show quoted text
> i've looked briefly at the code, but i'm afraid i do not have any time > within the next week to spend on finding a fix.
I doubt someone will be able to "fix" v0.69 to make it act like v0.39, since the model of processing input has more than slightly changed. Nevertheless, you are, of course, welcome to suggest changes and provide patches. Show quoted text
> also, i've noticed that you've removed all pre-0.50 releases from your > directory. was that neccessary?
I think it was justified, because v0.50 was a major redo. FWIW, files that are marked for deletion via the PAUSE (Perl Authors Upload Server) interface, don't effectively get deleted, but are moved to the author's backpan directory. You can still fetch v0.39 from http://backpan.perl.org/authors/id/S/SC/SCHUBIGER/DateTime-Format-Natural-0.39.tar.gz, but I won't be able any longer to support this ancient version.
Subject: Re: [rt.cpan.org #34336] 0.50+ can't parse date that 0.36 could
Date: Mon, 24 Mar 2008 11:58:22 -0500
To: bug-DateTime-Format-Natural [...] rt.cpan.org
From: mike <pulsation [...] gmail.com>
On Fri, Mar 21, 2008 at 6:30 PM, Steven Schubiger via RT <bug-DateTime-Format-Natural@rt.cpan.org> wrote: Show quoted text
> I think it was justified, because v0.50 was a major redo. FWIW, files > that are marked for deletion via the PAUSE (Perl Authors Upload Server) > interface, don't effectively get deleted, but are moved to the author's > backpan directory. > You can still fetch v0.39 from > http://backpan.perl.org/authors/id/S/SC/SCHUBIGER/DateTime-Format-Natural-0.39.tar.gz, > but I won't be able any longer to support this ancient version.
awesome. that'll work. thanks. -mike