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