Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> writes: > ISO 8601 permits "reduced precision" time representations to omit the > seconds value or both the minutes and the seconds values. The > abbreviate times could look like 17:45 or 1745 to omit the seconds, > or simply as 17 to omit both the minutes and the seconds. > > parse_date_basic accepts the 17:45 format but it rejects the other two. > Change it to accept 4-digit and 2-digit time values when they follow a > recognized date and a 'T'. > > Before this change: > > $ TZ=UTC test-tool date approxidate 2022-12-13T23:00 2022-12-13T2300 2022-12-13T23 > 2022-12-13T23:00 -> 2022-12-13 23:00:00 +0000 > 2022-12-13T2300 -> 2022-12-13 23:54:13 +0000 > 2022-12-13T23 -> 2022-12-13 23:54:13 +0000 > > After this change: > > $ TZ=UTC helper/test-tool date approxidate 2022-12-13T23:00 2022-12-13T2300 2022-12-13T23 > 2022-12-13T23:00 -> 2022-12-13 23:00:00 +0000 > 2022-12-13T2300 -> 2022-12-13 23:00:00 +0000 > 2022-12-13T23 -> 2022-12-13 23:00:00 +0000 > > Note: ISO 8601 also allows reduced precision date strings such as > "2022-12" and "2022". This patch does not attempt to address these. > > Reported-by: Pat LaVarre <plavarre@xxxxxxxxxxxxxxx> > Signed-off-by: Phil Hord <phil.hord@xxxxxxxxx> > Signed-off-by: Đoàn Trần Công Danh <congdanhqx@xxxxxxxxx> > --- > > Since this is a complete re-implementation from Phil Hord's version. > I'm reassigning the author to me. > > This version change the implementation to only treat the string as ISO8601 if > a 'T' existed and date has been parsed. I also added a test for parsing > RFC-822, which Hord accidentally broke. > > The commit message has been changed: > * The example has been changed to be independent from local timezone > * Remove the mention of adding test-cases, since it's obviously necessary. Will replace Phil's patch with this (hence even under your authorship, the topic name will be reused). Thanks, both.
