Open stof opened 1 week ago
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:
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.
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 type3
).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:
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)1
)!
following the opening bracked), the processing must, which should be reported as an error in PHP (like other invalid dates).