Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54324 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16442 invoked from network); 3 Aug 2011 20:03:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Aug 2011 20:03:05 -0000 Authentication-Results: pb1.pair.com header.from=scope@planetavent.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=scope@planetavent.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain planetavent.de from 89.107.186.104 cause and error) X-PHP-List-Original-Sender: scope@planetavent.de X-Host-Fingerprint: 89.107.186.104 xa8.serverdomain.org Received: from [89.107.186.104] ([89.107.186.104:46242] helo=xa8.serverdomain.org) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B4/35-23811-579A93E4 for ; Wed, 03 Aug 2011 16:03:02 -0400 Received: from [10.0.0.21] (ip-178-202-22-28.unitymediagroup.de [178.202.22.28]) (Authenticated sender: xa8190p1) by xa8.serverdomain.org (xa8.serverdomain.org) with ESMTPSA id 5BDFC282FA8CA for ; Wed, 3 Aug 2011 22:02:57 +0200 (CEST) Message-ID: <4E39A974.7080405@planetavent.de> Date: Wed, 03 Aug 2011 22:03:00 +0200 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: internals@lists.php.net References: <4E397879.4080007@planetavent.de> <20110803192954.GA8856@joeysmith.com> In-Reply-To: <20110803192954.GA8856@joeysmith.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] BUG 55240 - wrong date creation From: scope@planetavent.de (Nicolai Scheer) Hi! On 03.08.2011 21:29, Joey Smith wrote: >> 2011/8/4 Nicolai Scheer : >>> Hi! >>> >>> Did anyone had the time to review bug 55240 >>> (https://bugs.php.net/bug.php?id=55240), yet? >>> > > 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