[php-src] Issue #14668: Add support for formatting and creating dates from format for the RFC 9557 format
| From: | stof | Date: | Wed, 26 Jun 2024 09:51:57 +0000 |
| Subject: | [php-src] Issue #14668: Add support for formatting and creating dates from format for the RFC 9557 format | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-247151@lists.php.net to get a copy of this message | ||
Issue: https://github.com/php/php-src/issues/14668
Author: stof
### Description
[RFC 9557](https://datatracker.ietf.org/doc/rfc9557/) defines an extension of the RFC 3339 format.
As this format is used as the string representation for the [proposed
JS Temporal
API](https://tc39.es/proposal-temporal/) (currently being implemented by the major browsers, so
likely to ship in a few months), it would be great to be able to use this format in PHP in order to
interoperate with JS.
The format used in the Temporal API is described at https://tc39.es/proposal-temporal/docs/#string-persistence-parsing-and-formatting
As DatetimeImmutable does not support changing the calendar in PHP, and the default calendar in the
JS Temporal API is the ISO 8601 calendar, I think the calendar extension can be omitted. However, I
would expect this formatting to include the timezone extension when the DatetimeImmutable being
formatted is associated with a IANA timezone (i.e. a DateTimeZone of type 3).
When creating a date from a RFC 9557 format, I would expect PHP to read the timezone extension to
assign the appropriate timezone in the class using a IANA timezone. There are 2 cases to handle
here:
- RFC 9557 redefines the meaning of the Z suffix, which has an impact when combining it
with a timezone extension (the RFC 3339 date should be considered as being the value in UTC, and
then get converted to the IANA timezone, as documented by the example in section 3.3 of the RFC)
- if the string defines both a timezone offset and a timezone name, they might be inconsistent. The
way to handle that is defined in the RFC:
- if the timezone extension is elective, it can be ignored, treating it as if it were not there
(and so parsing only the timezone offset, producing a DatetimeImmutable with a DateTimeZone of type
1)
- if the timezone extension is critical (indicated by a ! following the opening
bracked), the processing must, which should be reported as an error in PHP (like other invalid
dates).