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 > > > > >
