# BUG 55240 - wrong date creation - Thread: https://externals.io/message/54319 - Original archive: https://news-web.php.net/php.internals/54319 - Started by Nicolai Scheer on 2011-08-03T16:34:01+00:00 - Messages: 7 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #54319 — Nicolai Scheer — 2011-08-03T16:34:01+00:00 URL: https://externals.io/message/54319#54319 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 --- ## #54320 — Laruence — 2011-08-03T17:06:38+00:00 URL: https://externals.io/message/54319#54320 · In reply to: #54319 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 : > 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 > > -- > > > > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #54322 — Joey Smith — 2011-08-03T19:29:54+00:00 URL: https://externals.io/message/54319#54322 · In reply to: #54320 > 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 : > > […] 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. :) --- ## #54323 — Joey Smith — 2011-08-03T19:36:53+00:00 URL: https://externals.io/message/54319#54323 · In reply to: #54322 > DateTime::createFromFormat("dn", "118") > -- Did you mean "August 11th", "November 8th", or "June 1st"? Pardon my idiocy, here - it's quite clear that "November 8th" wouldn't be a possible meaning here - I collapsed a couple of examples together and failed to fix the commentary. --- ## #54324 — Nicolai Scheer — 2011-08-03T20:03:00+00:00 URL: https://externals.io/message/54319#54324 · In reply to: #54322 Hi! > > […] > > 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'.) Unfortunately, there's nothing I could do about the strings to be parsed (in terms of customer agreement...). "24-hour format without leading zeroes" is exactly what I had expected from the 'G' format as well. "24-hour" somehow implies "not greater than 24". On the other hand "overflow" handling might be expected (and even a good thing to do?). Let's see what others are about to comment on the issue... Personally I'd vote for "fixing" this by limiting the parsed value. Another possibility would be to introduce a new format without the "overflow handling"... Greetings, Nico --- ## #54325 — Derick Rethans — 2011-08-03T20:10:04+00:00 URL: https://externals.io/message/54319#54325 · In reply to: #54324 > > > […] > > Unfortunately, there's nothing I could do about the strings to be parsed > (in terms of customer agreement...). > > "24-hour format without leading zeroes" is exactly what I had expected > from the 'G' format as well. "24-hour" somehow implies "not greater than > 24". On the other hand "overflow" handling might be expected (and even a > good thing to do?). > > Let's see what others are about to comment on the issue... > Personally I'd vote for "fixing" this by limiting the parsed value. > Another possibility would be to introduce a new format without the > "overflow handling"... Yes, this needs fixing. I am not sure how easy this is though... I've assigned the bug to myself. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug --- ## #54326 — Lonny Kapelushnik — 2011-08-03T20:18:53+00:00 URL: https://externals.io/message/54319#54326 · In reply to: #54325 In the `date()` function the formats are split up. In `date()` G is w/o leading zeros and H is w/ leading zeros. Why were these (as well as many others) combined and turned into an either/or for DateTime::createFromFormat? > > > > […] > > Yes, this needs fixing. I am not sure how easy this is though... > I've assigned the bug to myself. > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug