Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116296
MIME-Version: 1.0
References: <CAF+90c9crhPpSMcTx-ozGo0LGjNuBU43e8fiK_=PJMU6iTHNmw@mail.gmail.com>
 <28be190c-21ea-b796-cec7-b8db21d14eca@gmail.com> <b195f5db-cd29-93e6-d371-42ed42486a23@gmx.de>
 <CAJmy8YGn=BL6B4GeeOMENv0ZtD=YuKwPM9aMVdvCFyAyoPw9nQ@mail.gmail.com> <CAF+90c8wht+LpERZxj-XuY4sAYek8fH9hH_fc+JVZYg_yiAMpw@mail.gmail.com>
In-Reply-To: <CAF+90c8wht+LpERZxj-XuY4sAYek8fH9hH_fc+JVZYg_yiAMpw@mail.gmail.com>
Date: Mon, 25 Oct 2021 11:37:17 +0200
Message-ID: <CAJmy8YGP+nGXp4AHC__+F-3ubmO+Xxh0RqOYLiKwPb6hA5oU0Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000007da43105cf2a1d92"
Subject: Re: [PHP-DEV] Deprecation of ext/date ISO8061 constants
From: divinity76@gmail.com (Hans Henrik Bergan)

--0000000000007da43105cf2a1d92
Content-Type: text/plain; charset="UTF-8"

>> the topic was controversial

> Why is that? I did not found any information regarding this one on =
internals mailing list.

mostly because people who have never read the actual ISO8601 specs, or have
just skimmed it,
swear that "yeah it's totally legal, trust me bro".. and they're loud.

it's easy to make that mistake, as the ISO8601 specs is a huge complex
mess, and does allow a shit-ton of different formats, like for example:
R8/PT72H
what does that mean, you ask? i think it means "8 repetitions over 72
hours", but i don't recall for sure.
how about P2Y10M15DT10H30M20S
i think it means 2 years 10 months~
how about R/P1Y2M15DT12H/1985-04-12T23:20:50
i think that means "something with an unknown amount of repetitions that
started in 1985 and repeated for 1 year 2 months~"
,  but i don't actually remember..

but as someone who has actually read the specs (at least the 2004 edition),
i can say with confidence that PHP's DateTime::ISO8601 is not legal in
ISO8601:2004.

also i doubt it ever was legal in any revision of ISO8601 to mix
basic-with-extended, but i don't actually know that. (did the original 1988
revision of ISO8601 allow mixing basic format with extended format? i don't
know.)



On Sun, 05 Sep 2021 at 06:01, Damian Dziaduch <ddziaduch () icloud ! com>
wrote:

> From php-internals  Sun Sep 05 06:01:52 2021
>> From: Damian Dziaduch <ddziaduch () icloud ! com>
>> Date: Sun, 05 Sep 2021 06:01:52 +0000
>> To: php-internals
>> Subject: [PHP-DEV] Deprecation of ext/date ISO8061 constants
>> Message-Id: <03FA66B8-D164-496C-93D4-B70B9874BB6B () icloud ! com>
>> X-MARC-Message: https://marc.info/?l=php-internals&m=163082172305890
>>
>> Hello internals!
>>
>> This is my first time writing here :)
>>
>> The deprecation was originally added in RFC Deprecations for PHP 8.1, =
>> but in a later stage dropped entirely:
>> =https://wiki.php.net/rfc/deprecations_php_8_1?do=3Ddiff&rev2%5B0%5D=3D1623=
>> 754059&rev2%5B1%5D=3D1623759320&difftype=3Dsidebyside
>>
>> It was already discussed on this mailing list:
>> > List:       php-internals
>> > Subject:    Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
>> > From:       Nikita Popov <nikita.ppv () gmail ! com>
>> > Date:       2021-06-15 12:23:50
>> > Message-ID: CAF+90c8wht+LpERZxj-XuY4sAYek8fH9hH_fc+JVZYg_yiAMpw () =
>> mail ! gmail ! com
>> >=20
>> > On Tue, Jun 15, 2021 at 12:48 PM Hans Henrik Bergan =
>> <divinity76@gmail.com>
>> > wrote:
>> >=20
>> >> i don't like this part of the RFC:
>> >=20
>> >=20
>> >>> There's a number of bug reports related to this. =46rom what I =
>> understand,
>> >>> the core problem here is not that the ISO8601 format is *wrong*, =
>> it's just
>> >>> one of multiple legal ISO-8601 formats. As DateTime formats always =
>> refer to
>> >>> a specific format, not a set of multiple possible ones, there =
>> doesn't seem
>> >>> to be anything actionable here.
>> >>=20
>> >> - this is wrong, DateTime::ISO8601 *is* illegal in ISO8601.
>> >> quoting ISO8601:2004 section 4.3.3:
>> >>=20
>> >>> For reduced accuracy, decimal or expanded representations of date =
>> and
>> >>> time of day, any of the representations in 4.1.2 (calendar dates), =
>> 4.1.3
>> >>> (ordinal dates) or 4.1.4 (week dates) followed immediately by the =
>> time
>> >>> designator [T] may be combined with any of the representations in =
>> 4.2.2.2
>> >>> through 4.2.2.4 (local time), 4.2.4 (UTC of day) or 4.2.5.2 (local =
>> time and
>> >>> the difference from UTC) provided that (...skipped stuff...) d) the
>> >>> expression shall either be completely in basic format, in which case =
>> the
>> >>> minimum number of separators necessary for the required expression =
>> is used,
>> >>> or completely in extended format, in which case additional =
>> separators shall
>> >>> be used in accordance with 4.1 and 4.2.
>> >>=20
>> >> DateTime::ISO8601 does exactly what part "d" says isn't legal,
>> >> 1970-01-01T01:00:00 is extended format, and +0100 is basic format, =
>> breaking
>> >> the "the expression shall either be completely in basic format, in =
>> which
>> >> case the minimum number of separators necessary for the required =
>> expression
>> >> is used, or completely in extended format" -part. " =
>> 1970-01-01T01:00:00" is
>> >> legal extended format but illegal basic format, and "+0100" is legal =
>> basic
>> >> format but illegal extended format, and mixing the 2 isn't legal.
>> >=20
>> > Thanks for the reference. I've removed the mention of =
>> DateTime::ISO8601
>> > from the RFC to make sure that the RFC text doesn't make any incorrect
>> > statements. Not going to include a deprecation proposal as part of =
>> this RFC
>> > though -- from past discussions, the topic was controversial, so I =
>> don't
>> > want to include it this late in the process.
>>
>> I do understand why it was dropped entirely from RFC, but I do not =
>> understand this part:
>>
>> > the topic was controversial
>>
>> Why is that? I did not found any information regarding this one on =
>> internals mailing list.
>>
>> Kind regards.
>>
>>

--0000000000007da43105cf2a1d92--