-
Notifications
You must be signed in to change notification settings - Fork 7.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for formatting and creating dates from format for the RFC 9557 format #14668
Comments
Two parts: the change regarding 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 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:
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).The text was updated successfully, but these errors were encountered: