Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114886
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: Tue, 15 Jun 2021 15:54:09 +0200
Message-ID: <CAJmy8YFK5_iJHciodCigW2Ofe1Q-=dAM8OXU7Hqeu5N-X+xJjA@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000019dc9305c4ce51a2"
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
From: divinity76@gmail.com (Hans Henrik Bergan)

--00000000000019dc9305c4ce51a2
Content-Type: text/plain; charset="UTF-8"

thanks

> 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.

That's fine by me.

> the topic was controversial

indeed it is/was (at least on Reddit)

On Tue, 15 Jun 2021 at 14:24, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Jun 15, 2021 at 12:48 PM Hans Henrik Bergan <divinity76@gmail.com>
> wrote:
>
>> i don't like this part of the RFC:
>>
>> > There's a number of bug reports related to this. From 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.
>>
>> - this is wrong, DateTime::ISO8601 *is* illegal in ISO8601.
>> quoting ISO8601:2004 section 4.3.3:
>>
>> > 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.
>>
>> 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.
>>
>
> 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.
>
> Regards,
> Nikita
>
>
>> On Tue, 15 Jun 2021 at 12:33, Christoph M. Becker <cmbecker69@gmx.de>
>> wrote:
>>
>> > On 23.03.2021 at 06:04, Stanislav Malyshev wrote:
>> >
>> > >> t fopen mode
>> > >
>> > > I'm afraid there's - despite the warning - a bunch of code for Windows
>> > > that relies on "t" and I don't think we should be breaking it. Is
>> there
>> > > a good reason to drop this mode?
>> >
>> > I don't see much need for 't' mode nowadays.  Even Notepad properly
>> > handles LF fine for some years now.  It's not really bad, if it can be
>> > explicitely specified.  However, deprecating 't' mode would pave the way
>> > to sometime change shell_exec() to no longer use 't' mode, what is a
>> > footgun when dealing with binary data.  So when using the backtick
>> > operator on Windows, you always need to keep that in mind.  From my
>> > experience, 't' mode causes more harm than good.
>> >
>> > And if there is really the need for LF conversion, that still can be
>> > done with an explicit filter.
>> >
>> > --
>> > Christoph M. Becker
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: https://www.php.net/unsub.php
>> >
>> >
>>
>

--00000000000019dc9305c4ce51a2--