Hi !
Sorry derick for the duplicated email but I was not registered.
This is my first contribution, so I would appreciate any help on the
proposal and on following the project's contribution process.
I opened issue #23491 for a possible addition to ext/date:
https://github.com/php/php-src/issues/23491
I would appreciate feedback before preparing an implementation.
PHP currently provides DATE_RFC3339_EXTENDED, which includes millisecond
precision. For a UTC DateTime, it produces:
1970-01-01T00:00:00.000+00:00
Some applications need the equivalent representation with the ISO 8601 UTC
designator Z:
1970-01-01T00:00:00.000Z
This is also the format produced by JavaScript's
Date.prototype.toISOString():
new Date(0).toISOString();
// "1970-01-01T00:00:00.000Z"
Would a predefined format for this representation be appropriate for
ext/date?
One possible API would be:
DATE_ISO8601_MILLISECONDS_UTC
DateTimeInterface::ISO8601_MILLISECONDS_UTC
with the format string:
"Y-m-d\\TH:i:s.v\\Z"
For example:
$date = new DateTimeImmutable('@0');
echo $date->setTimezone(new DateTimeZone('UTC'))
->format(DATE_ISO8601_MILLISECONDS_UTC);
// 1970-01-01T00:00:00.000Z
The name and API shape are open for discussion. Another option would be an
offset-preserving format:
DATE_ISO8601_MILLISECONDS
DateTimeInterface::ISO8601_MILLISECONDS
using:
"Y-m-d\\TH:i:s.vP"
I understand that date format constants only define formatting; they do not
change the timezone of the DateTime object.
A format containing a literal Z would therefore require the caller to
normalize the object to UTC first.
For context, issue #14593 discusses the interpretation of the Z suffix when
parsing DateTime values:
https://github.com/php/php-src/issues/14593
That issue concerns parsing and timezone representation, whereas this
proposal concerns predefined formatting constants.
I would appreciate feedback on:
1. Whether a millisecond-precision format is useful in addition to
DATE_RFC3339_EXTENDED.
2. Whether an offset-preserving format or a UTC-suffix format is preferable.
3. Whether the proposed names follow the preferred ext/date convention.
4. Whether an RFC is required before implementation.
Thank you,
Théo Attali
