Add a UTC-normalizing DateTime method for ISO 8601 output
还没有人认领这个 Issue。
评估
调研方向
首先查看现有的日期格式化常量以及 ext/date 中 DateTime 的行为,尤其是 DATE_RFC3339_EXTENDED 和 UTC 转换。阅读链接的评论以了解首选的方法方向;当 API 形态达成一致,并且该方法生成具有毫秒精度和 Z 后缀、已规范化为 UTC 的 ISO 8601 输出时,即表示完成。
由索引模型根据 Issue 内容生成。
描述
Update: Based on feedback, this proposal no longer focuses on adding a
format constant. The preferred direction under discussion is a method that
normalizes the represented instant to UTC and returns ISO 8601 output with
millisecond precision and aZsuffix. Check this comment : https://github.com/php/php-src/issues/23491#issuecomment-5464152132
Spoiler old proposal
## DescriptionPHP provides predefined date format constants such as DATE_ISO8601,
DATE_ATOM, DATE_RFC3339, and DATE_RFC3339_EXTENDED. There is no predefined
format for the UTC timestamp commonly produced by JavaScript:
1970-01-01T00:00:00.000Z
For example:
new Date(0).toISOString();
// "1970-01-01T00:00:00.000Z"
Proposal
Add a predefined format for ISO 8601 timestamps with millisecond precision.
One possible name is:
DATE_ISO8601_MILLISECONDS_UTC
DateTimeInterface::ISO8601_MILLISECONDS_UTC
with the format string:
"Y-m-d\\TH:i:s.v\\Z"
The name and API shape are open for discussion.
An alternative is an offset-preserving format:
DATE_ISO8601_MILLISECONDS
DateTimeInterface::ISO8601_MILLISECONDS
using:
"Y-m-d\\TH:i:s.vP"
Example
$date = new DateTimeImmutable('@0');
echo $date->setTimezone(new DateTimeZone('UTC'))
->format(DATE_ISO8601_MILLISECONDS_UTC);
// 1970-01-01T00:00:00.000Z
As with the existing date format constants, formatting does not change the
timezone of the DateTime object. The caller must convert it to UTC before
using the _UTC format.
Existing constant
DATE_RFC3339_EXTENDED already includes milliseconds, but produces an offset:
1970-01-01T00:00:00.000+00:00
This is semantically equivalent to Z for UTC, but is not byte-for-byte
compatible with JavaScript's Date.prototype.toISOString().
Related discussion
PHP issue #14593 discusses the
interpretation of the Z suffix when parsing DateTime values. That issue is
about parsing and timezone representation; this proposal is about predefined
formatting constants in ext/date.
Questions
- Is a millisecond-precision constant useful in addition to
DATE_RFC3339_EXTENDED? - Should the format preserve the object's offset, or provide the
Zform for
UTC-normalized values? - What name and API shape should be used?
- Would both forms introduce unnecessary overlap with the existing constants?
- 主要语言
- C
- 星标
- 40.4k
- 派生
- 8.2k
- 平均合并
- 2 天 17 小时
- 30 天内合并 PR
- 115
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
php/php-src 的其他 Issue
-
Bug Status: Needs Triage
难度 2/5 1-3 小时 新手友好度 76/100
-
Bug Status: Needs Triage
难度 1/5 1 小时以内 新手友好度 90/100
-
Bug Status: Needs Triage
难度 2/5 1-3 小时 新手友好度 78/100
-
Bug Category: Tests Status: Verified
难度 2/5 1-3 小时 新手友好度 68/100
-
Bug SAPI: fpm Status: Needs Triage
难度 2/5 1-3 小时 新手友好度 65/100
相似的 Issue
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
bradcypert/plum#53 ·
-
Component: GLib
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 75/100
-
Status: Opened
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 75/100
nextbsd/nextbsd-userland#285 ·