Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114885
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>
In-Reply-To: <CAJmy8YGn=BL6B4GeeOMENv0ZtD=YuKwPM9aMVdvCFyAyoPw9nQ@mail.gmail.com>
Date: Tue, 15 Jun 2021 14:23:50 +0200
Message-ID: <CAF+90c8wht+LpERZxj-XuY4sAYek8fH9hH_fc+JVZYg_yiAMpw@mail.gmail.com>
To: Hans Henrik Bergan <divinity76@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d5893705c4cd0c32"
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000d5893705c4cd0c32
Content-Type: text/plain; charset="UTF-8"

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
> >
> >
>

--000000000000d5893705c4cd0c32--