BUG 55240 - wrong date creation

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

--

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. :)