Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:54322
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain joeysmith.com designates 209.90.98.146 as permitted sender)
Date: Wed, 3 Aug 2011 13:29:54 -0600
To: internals@lists.php.net
Message-ID: <20110803192954.GA8856@joeysmith.com>
References: <4E397879.4080007@planetavent.de>
 <CABBJUpf+FPB3uewoPxVyHHj6sWhPdMqXY4Vns-grjgA5BKLdWg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABBJUpf+FPB3uewoPxVyHHj6sWhPdMqXY4Vns-grjgA5BKLdWg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [PHP-DEV] BUG 55240 - wrong date creation
From: joey@php.net (Joey Smith)

On Thu, Aug 04, 2011 at 01:06:38AM +0800, Laruence wrote:
> Hi:
>    I read the ext/date/lib/parse_date.c, and I think this could not be a bug ,
>    since 800 will be think as 80h 0min(timelib_get_nr is common
> function, to get number from data description string with fixed max
> length),
>    than 11 + (80 / 24)  ~= 14
> 
>  thanks
> 
> 2011/8/4 Nicolai Scheer <scope@planetavent.de>:
> > Hi!
> >
> > Did anyone had the time to review bug 55240
> > (https://bugs.php.net/bug.php?id=55240), yet?
> >
> > So far it just has been adjusted to reflect the right package.
> >
> > Any pointers are welcome!
> >
> > Grettings,
> >
> > Nico
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >

It definitely appears to be unexpected behaviour - the 'G' format for
hours is "24-hour format without leading zeroes" - so the expectation
would be that 'Gi' parses '800' as '8 hours and 0 minutes'. (Also, I
thought I would point out here that the comments on 'G' and 'H', in
timelib_parse_from_format are backwards here - same with 'g' and 'h'.)

It's an ambiguous format...you would have the same issue with 'g' or
'n', here...timelib_get_nr() is going to consume as many numbers as it
can (2) unless it hits a non-number first.

Just some examples:

DateTime::createFromFormat("dn", "118")
 -- Did you mean "August 11th", "November 8th", or "June 1st"?
DateTime::createFromFormat("gi", "800")
 -- This is an actual error, as 'g' rejects values higher than 12

The simplest "fix" here is probably to have 'G' throw the same error
as 'g' when the hours component is greater than 24 - however, I don't
think it would be that much harder to have both 'g' and 'G' do the
expected thing, here: push the pointer back two characters and try
again with a max_length of 1 to see if they can parse it that way.
The question, I suppose, is whether that's something we WANT to do -
I had written about half of the required patch before I thought I
should probably ask the question first. :)