Add support for formatting and creating dates from format for the RFC 9557 format

[stof]

Description

RFC 9557 defines an extension of the RFC 3339 format.

As this format is used as the string representation for the proposed JS Temporal API (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).

[damianwadley]

Two parts: the change regarding Z and the stuff about suffixes. The stuff with Z is, if I read this correctly, already supported by PHP so there's nothing to do here.

For suffixes, I see a couple problems:

1. Unlike every other format, this is not fixed. It cannot be represented with formatting placeholders in any sort of system designed to parse known-format strings - not just PHP.
2. The embedded logic of critical vs. non-critical. Suddenly there is now syntax with meanings that go beyond a character being a separator or representing a specific component of a date/time.
3. Suffixes are practically arbitrary. They're metadata being encoded into the string instead of, say, opting for a non-scalar data exchange format like JSON.

The only way I see supporting this is to add it to strtotime's flexible parsing; I don't see how it could work with createFromFormat. But that would also mean dropping all (non-critical) metadata information, other than the timezone. Calendar information is also outside the scope of PHP's DateTime functionality as that's just too much complexity to have to manage (especially given that ext/intl exists).

I mean, either that or create a whole new "create from IXDTF" function, which is a slippery slope.

Frankly, this sounds more like a job for the ICU library (which powers ext/intl) to handle.

[stof]

To support interoperability with Temporal, we don't need support for arbitrary metadata actually. We don't even need support for calendars in DateTimeImmutable as this class handles only the ISO 8601 calendar (which is the default calendar in Temporal and so does not require to be specified explicitly).

What we mostly need is support for the timezone name. I think this could be solved by introducing a new formatting placeholder for this RFC 9557 timezone name, which would work this way:

• for a DateTimeZone of type 3, produce the timezone identifier wrapped in square brackets
• for other timezone types, produce an empty string
  The format constant for RFC 9557 would then use both the existing P placeholder (or maybe p, to be checked, or maybe a new one to distinguish Z for UTC from +00:00 for Europe/London in winter time for instance) and this new placeholder.

For parsing of date string, the handling of strings containing both a timezone offset and a timezone name should work as described in my opening message.