Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120367
MIME-Version: 1.0
References: <CAPTD5yHUdoqZ8AA5LzkHY784W2L3mHj2yrazWrGzha7xZ101NQ@mail.gmail.com>
 <ada65004-742f-4d21-96f7-e6c3b21e7f80@app.fastmail.com> <CAPTD5yE8z75DPpL_5NJ1n_KvGxmr_m-xyekqvntv-2+twYaLpw@mail.gmail.com>
In-Reply-To: <CAPTD5yE8z75DPpL_5NJ1n_KvGxmr_m-xyekqvntv-2+twYaLpw@mail.gmail.com>
Date: Sat, 20 May 2023 11:38:02 +0200
Message-ID: <CAJmy8YH7Ar84FoTfZRkDSptLdf32RaXgNdCJXkWDrQ44=wP3TQ@mail.gmail.com>
To: Jorg Sowa <jorg.sowa@gmail.com>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000004dbedd05fc1ccca1"
Subject: Re: [PHP-DEV] Deprecation of the formats DATE_ISO8601 and DATE_RFC7231
From: divinity76@gmail.com (Hans Henrik Bergan)

--0000000000004dbedd05fc1ccca1
Content-Type: text/plain; charset="UTF-8"

>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

On Fri, May 19, 2023, 23:17 Jorg Sowa <jorg.sowa@gmail.com> wrote:

> > 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'.
>

--0000000000004dbedd05fc1ccca1--