Phil Hord <phil.hord@xxxxxxxxx> writes: > From: Phil Hord <phil.hord@xxxxxxxxx> > > 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. > Fix it to accept 4-digit and 2-digit time values when they follow a > recognized date but no time has yet been parsed. I worry a bit that this may conflict with other approxidate heuristics. > $ test-tool date approxidate 2022-12-13T23:00 2022-12-13T2300 2022-12-13T23 > 2022-12-13T23:00 -> 2022-12-14 07:00:00 +0000 > 2022-12-13T2300 -> 2022-12-14 07:00:00 +0000 > 2022-12-13T23 -> 2022-12-14 07:00:00 +0000 All of these may be obvious improvements, but the thing is that there is nothing in the approxidate parsing code that insists on the presence of "T" to loosen the rule only for ISO-8601 case. For example, with only 6 digits, do we still recognise our internal timestamp format (i.e. seconds since epoch) without the disambiguating '@' prefix?
