Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114883
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>
In-Reply-To: <b195f5db-cd29-93e6-d371-42ed42486a23@gmx.de>
Date: Tue, 15 Jun 2021 12:47:56 +0200
Message-ID: <CAJmy8YGn=BL6B4GeeOMENv0ZtD=YuKwPM9aMVdvCFyAyoPw9nQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000011e6d505c4cbb7c4"
Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 8.1
From: divinity76@gmail.com (Hans Henrik Bergan)

--00000000000011e6d505c4cbb7c4
Content-Type: text/plain; charset="UTF-8"

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.




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
>
>

--00000000000011e6d505c4cbb7c4--