# Deprecation of the formats DATE_ISO8601 and DATE_RFC7231 - Thread: https://externals.io/message/120363 - Original archive: https://news-web.php.net/php.internals/120363 - Started by Jorg Sowa on 2023-05-19T20:49:46+00:00 - Messages: 10 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #120363 — Jorg Sowa — 2023-05-19T20:49:46+00:00 URL: https://externals.io/message/120363#120363 Hello everyone, I would like to propose the deprecation of the constants DATE_ISO8601, DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231. Arguments for deprecating DATE_ISO8601: - outdated format, standard has been changed while ago - incompatible with format ISO8601_EXPANDED - misleading behavior for developers [1] [2] - doesn't support microseconds [3] - many misunderstandings in the userland [4] [5] In my opinion the question is not whether this constant should be deprecated, but when. I know that the problem was discussed in the past, but I hope enough time has passed already to touch this topic again although of the BC nature. [6] [7] Arguments for deprecating DATE_RFC7231: - error prone nature, the format never really supported timezone. I'm not sure how it appeared in the code, but tests clearly lack cases for this format. I'm not sure if it was missed on purpose, but with tests it would be obvious that the format shouldn't ever appear in the core. [8] [9] It's my first proposition in the PHP Core and I'm not sure if I should suggest it through RFC or normal discussion like this. If I should propose it in RFC then I can prepare it along with PR. Kind regards, Jorg --- ## #120365 — Larry Garfield — 2023-05-19T20:55:44+00:00 URL: https://externals.io/message/120363#120365 · In reply to: #120363 > Hello everyone, > > I would like to propose the deprecation of the constants DATE_ISO8601, > DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231. > > Arguments for deprecating DATE_ISO8601: > - outdated format, standard has been changed while ago > - incompatible with format ISO8601_EXPANDED > - misleading behavior for developers [1] > > [2] > > - doesn't support microseconds [3] > > - many misunderstandings in the userland [4] > > [5] > > In my opinion the question is not whether this constant should be > deprecated, but when. I know that the problem was discussed in the past, > but I hope enough time has passed already to touch this topic again > although of the BC nature. [6] > [7] > > > Arguments for deprecating DATE_RFC7231: > - error prone nature, the format never really supported timezone. I'm not > sure how it appeared in the code, but tests clearly lack cases for this > format. I'm not sure if it was missed on purpose, but with tests it would > be obvious that the format shouldn't ever appear in the core. [8] > [9] > > > It's my first proposition in the PHP Core and I'm not sure if I should > suggest it through RFC or normal discussion like this. If I should propose > it in RFC then I can prepare it along with PR. > > Kind regards, > Jorg How common is it in the wild? I am pretty sure I've used it myself without really thinking many times, which I suspect is common. Knowing how much code would be impacted would determine how we'd go about deprecating it and on what timeline. --Larry Garfield --- ## #120366 — Jorg Sowa — 2023-05-19T21:16:40+00:00 URL: https://externals.io/message/120363#120366 · In reply to: #120365 > How common is it in the wild? I am pretty sure I've used it myself without really thinking many times, which I suspect is common. Knowing how much code would be impacted would determine how we'd go about deprecating it and on what timeline. I'm not sure how would be possible to find out. I suppose most of the frameworks (and thus popular PHP libraries) avoid this constant as showed in Drupal and Carbon. The scanning of popular libraries will not show the scale of the problem (however I will do it tomorrow) Helpful fact is that those constants are just constants so it's easily replaceable with strings 'Y-m-d\\TH:i:sO' and 'D, d M Y H:i:s \\G\\M\\T'. --- ## #120367 — Hans Henrik Bergan — 2023-05-20T09:38:02+00:00 URL: https://externals.io/message/120363#120367 · In reply to: #120366 >outdated format, standard has been changed while ago What do you mean? Do you mean that the constant was legal at some point? Was there ever a version of ISO8601 allowing the mixing of "extended format" and "basic format" ? The earliest version I've read, iso8604:2004, does not allow it (more on that here: https://externals.io/email/114883/source - can't find the proper link right now, am on phone). Haven't read the older 1988/1999/2000 versions, and it's possible one of those allowed it, but I doubt it. The only thing I can say for sure is that it's been illegal since the 2004 version > > […] > without really thinking many times, which I suspect is common. Knowing how > much code would be impacted would determine how we'd go about deprecating > it and on what timeline. > > I'm not sure how would be possible to find out. I suppose most of the > frameworks (and thus popular PHP libraries) avoid this constant as showed > in Drupal and Carbon. The scanning of popular libraries will not show the > scale of the problem (however I will do it tomorrow) Helpful fact is that > those constants are just constants so it's easily replaceable with > strings 'Y-m-d\\TH:i:sO' > and 'D, d M Y H:i:s \\G\\M\\T'. --- ## #120377 — Jorg Sowa — 2023-05-21T22:06:14+00:00 URL: https://externals.io/message/120363#120377 · In reply to: #120367 > What do you mean? Do you mean that the constant was legal at some point? Sorry, but I don't have this knowledge. It's invalid since 2004, but I suppose this format was implemented before then. Undoubtedly the format is invalid now. The usage in 1000 most popular libraries: DATE_ISO8601 (4 packages, 1 in comments) DateTimeInterface::ISO8601 (18 packages) DateTimeInterface::RFC7231 (1 package - Jetbrains/phpstorm-stubs) DATE_RFC7231 (1 package - Jetbrains/phpstorm-stubs) Most of the packages already inform about deprecation. PHP stubs by Jetbrans warn about deprecation, although it's not officially. --- ## #120402 — Derick Rethans — 2023-05-26T10:17:33+00:00 URL: https://externals.io/message/120363#120402 · In reply to: #120363 > I would like to propose the deprecation of the constants DATE_ISO8601, > DateTimeInterface::ISO8601 and DateTimeInterface::RFC7231, DATE_RFC7231. … > In my opinion the question is not whether this constant should be > deprecated, but when. I know that the problem was discussed in the past, > but I hope enough time has passed already to touch this topic again > although of the BC nature. [6] > [7] In my opinion, deprecating this does not do anything besides annoying users. > > Arguments for deprecating DATE_RFC7231: > - error prone nature, the format never really supported timezone. I'm not > sure how it appeared in the code, but tests clearly lack cases for this > format. I'm not sure if it was missed on purpose, but with tests it would > be obvious that the format shouldn't ever appear in the core. [8] > [9] > This should instead be fixed of being deprecated. It is a recent addition after all. cheers, Derick --- ## #120464 — Hans Henrik Bergan — 2023-05-30T16:26:14+00:00 URL: https://externals.io/message/120363#120464 · In reply to: #120402 >In my opinion, deprecating this does not do anything besides annoying users. In my opinion, since it isn't, and likely never was, a legal ISO8601 string, it's a no-brainer that it should be deprecated. (it's at least been illegal since iso8601:2004 released in 2004) > > > > > […] > > … > > > […] > > In my opinion, deprecating this does not do anything besides annoying > users. > > > […] > > This should instead be fixed of being deprecated. It is a recent > addition after all. > > cheers, > Derick > > -- > > To unsubscribe, visit: https://www.php.net/unsub.php --- ## #120514 — Hans Henrik Bergan — 2023-06-02T18:33:52+00:00 URL: https://externals.io/message/120363#120514 · In reply to: #120464 DATE_ISO8601 doesn't have to be removed anytime soon, but no new code should be written using that constant, thus an `E_DEPRECATED` is warranted. Is anyone really arguing against that statement? > > > […] > users. > > In my opinion, since it isn't, and likely never was, a legal ISO8601 > string, it's a no-brainer that it should be deprecated. (it's at least > been illegal since iso8601:2004 released in 2004) > > > > […] --- ## #120516 — Jorg Sowa — 2023-06-02T22:28:29+00:00 URL: https://externals.io/message/120363#120516 · In reply to: #120464 > In my opinion, since it isn't, and likely never was, a legal ISO8601 > string, it's a no-brainer that it should be deprecated. (it's at least > been illegal since iso8601:2004 released in 2004) I thought the same when I started the discussion. It's not good promotion for PHP, when every mention about using proper ISO8601 format starts with warning (use DATE_ATOM, not ISO_8601!). It doesn't need to be removed straight in PHP 9. We can wait for next major version. I just don't understand why keeping invalid concept in the language is important for such simple structure like constant. I understand it's BC, but it cannot be keep forever. I would write RFC anyway to check the reception, but I need Karma to do it. Could I ask someone for it? --- ## #120517 — Niels Dossche — 2023-06-02T22:31:26+00:00 URL: https://externals.io/message/120363#120517 · In reply to: #120516 > I would write RFC anyway to check the reception, but I need Karma to do it. > Could I ask someone for it? > You'll need to register on the wiki, and send an email to internals in which you say your wiki name. Kind regards Niels