[0/2] More ISO-8601 support

Message

Đoàn Trần Công Danh April 14, 2020, 9:31 a.m. UTC

On 2020-04-14 00:03:24+0000, "brian m. carlson" <[e-mail]> wrote:
> git-commit(1) claims we support ISO 8601 format.  However, our
> approxidate code misparses some dates with fractional seconds.

We have never fully supported ISO-8601, those representation are
perfectly valid ISO-8601 (for 2020-04-14) but it would require
more code to parse correctly, perhap "tm_wday" and "tm_yday",
and mktime may help.

	2020-W16-2
	--04-14
	2020-105

I don't think not many people interested in those formats.
If someone really need them, we can get back to them later.

> Reproduction:
> 
>   git init foo
>   cd foo
>   echo abc > abc.txt
>   git add .
>   git commit --date="2020-04-03T12:43:55.019-04:00”
> 
> This should produce Fri Apr 3 12:43:55 2020 -0400, but actually produces
> Sun Apr 19 12:43:55 2020 +0000 (at least on my system, which uses UTC).
> Note the different date, which is 16 days away from what is expected.
> 
> Since we claim to support ISO 8601, we need to either reject fractional
> seconds with an error, or accept and ignore them.  If what we really
> support is RFC 3339 (which I suspect it is), we need to do the latter,
> since that profile explicitly permits them in the syntax, as well as
> update the documentation accordingly.
> 
> This was originally reported at
> https://stackoverflow.com/questions/61193896/how-does-git-parse-date-string/61197722.
> I don't plan to send a patch for this right now, but I wanted to make

If we plan on supporting more format from ISO-8601, these 2 patches
can be used.

Đoàn Trần Công Danh (2):
  date.c: allow fractional second part of ISO-8601
  date.c: allow compact version of ISO-8601 datetime

 date.c          | 20 ++++++++++++++++++++
 t/t0006-date.sh |  4 ++++
 2 files changed, 24 insertions(+)

Comments

brian m. carlson April 14, 2020, 11:45 p.m. UTC | #1

On 2020-04-14 at 09:31:53, Đoàn Trần Công Danh wrote:
> On 2020-04-14 00:03:24+0000, "brian m. carlson" <[e-mail]> wrote:
> > git-commit(1) claims we support ISO 8601 format.  However, our
> > approxidate code misparses some dates with fractional seconds.
> 
> We have never fully supported ISO-8601, those representation are
> perfectly valid ISO-8601 (for 2020-04-14) but it would require
> more code to parse correctly, perhap "tm_wday" and "tm_yday",
> and mktime may help.
> 
> 	2020-W16-2
> 	--04-14
> 	2020-105
> 
> I don't think not many people interested in those formats.
> If someone really need them, we can get back to them later.

Yeah, I agree we don't need to support those.  I would be happy if we
said "RFC 3339", which is a more limited profile, and implemented that.
The problem, as you alluded to (and I did as well in my original
report), is that ISO 8601 provides a huge number of potential formats,
most of which are not interesting for typical software.