Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70357
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.50 as permitted sender)
Message-ID: <52924F20.2030204@gmail.com>
Date: Sun, 24 Nov 2013 14:10:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Bug #66156
From: mjpelmear@gmail.com (Matt Pelmear)

Evidently I've not been clear enough in my bug ticket #66156 
(https://bugs.php.net/bug.php?id=66156) so I'll bring it to the group here.

In Derick's comment (while marking this as "not a bug") he stated that 
"If you pass in an ambiguous string for a format, there is nothing we 
can do."

I agree completely. However, "!ndY" is *not* ambiguous. I think the 
ticket was just misread, since he mentioned "!jnY" specifically in his 
comment.

"!ndY" is a one or two digit number, followed by a two digit number, 
followed by a four digit number.
To use Derick's example, "1112013", when parsed with "!ndY", should be 
unambiguously January 11th, 2013 (because the date *must be* two digits, 
due to the use of "d").
There is no case that is ambiguous with this format, unless you are only 
thinking about parsing it from left-to-right. That doesn't make the 
format ambiguous; that just makes it incompatible with the current 
algorithm, which is fine.

All I'm suggesting is that if we don't plan to support this 
*unambiguous* date format properly (because of the effort involved in 
doing so), we should have an error message that indicates such a 
decision, as opposed to simply receiving bad output for a format that 
should work, regardless of how strange it is.
At the very least the official documentation should indicate that the 
algorithm always works from left to right, and as such could have 
unexpected results in some fringe cases. Maybe that is the best solution.

I've offered to do the work. I'm just looking for an agreement that an 
error message returned in the standard format for that method is acceptable.

I apologize for the degree of frustration here, but this is the second 
time I've submitted a ticket that was a real issue but was misread and 
dismissed. (The other issue was fixed afterward, when someone else 
raised the same issue on the list here.) This one might be a minor 
detail, but don't details matter?

-Matt