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....@gmail.com> wrote: > On Tue, Jun 15, 2021 at 12:48 PM Hans Henrik Bergan <divinit...@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 <cmbecke...@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 >> > >> > >> >
