>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) On Fri, 26 May 2023 at 12:17, Derick Rethans <der...@php.net> wrote: > > On Fri, 19 May 2023, Jorg Sowa wrote: > > > 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] <https://externals.io/message/113657#114885> > > [7] > > In my opinion, deprecating this does not do anything besides annoying > users. > > > <https://www.reddit.com/r/PHP/comments/hnd438/why_isnt_date_iso8601_deprecated/> > > 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] > > <https://www.php.net/manual/en/class.datetimeinterface.php> [9] > > <https://github.com/php/doc-en/pull/2296> > > This should instead be fixed of being deprecated. It is a recent > addition after all. > > cheers, > Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
