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 ·