On 2020-04-14 00:03:24+0000, "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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(+) -- 2.26.0.485.g518673e55f
