Bug report: Author/Commit date in ISO 8601 format

Bug report: Author/Commit date in ISO 8601 format

[Oliver Busch]

Dear git community,

I encountered the following problem: When using the date formatting 
option ISO (either by setting --date=iso or using format:%ci for the 
committer date), the output is formatted like this:

2014-08-25 17:49:43 +0200

But according to ISO 8601, should be formatted like this (see 
http://www.w3.org/TR/NOTE-datetime):

2014-08-25T17:49:43+02:00

This difference makes it impossible to use automated string conversion 
(in my case, I tried to use Delphi's XSBuildIns 
(http://wiert.me/2011/07/19/iso-8601-delphi-way-to-convert-xml-date-and-time-to-tdatetime-and-back-via-stack-overflow/), 
which converted git's output "2014-08-25 17:49:43 +0200" to a TDateTime 
of "2014-08-25 02:00:00"; conversion worked correctly when using 
"2014-08-25T17:49:43+02:00" as input).

I therefore suggest to adapt the output when using --date=iso or 
format:%ci to comply 100% with the ISO 8601 specs, or at least change 
documentation to say the output is only "ISO-like".

Kind regards,

Oliver Busch

-- 

Oliver Busch, M.Eng.

Airport Research Center GmbH
Bismarckstraße 61
52066 Aachen
Germany

Phone: +49 241 16843-161
Fax: +49 241 16843-19
e-mail: Oliver.Busch@arc-aachen.de
Website: http://www.airport-consultants.com

Register Court: Amtsgericht Aachen HRB 7313
Ust-Id-No.: DE196450052

Managing Directors:
Dipl.-Ing. Tom Alexander Heuer

Re: Bug report: Author/Commit date in ISO 8601 format

[Jeff King]

On Tue, Aug 26, 2014 at 09:29:44AM +0200, Oliver Busch wrote:

> I encountered the following problem: When using the date formatting option
> ISO (either by setting --date=iso or using format:%ci for the committer
> date), the output is formatted like this:
> 
> 2014-08-25 17:49:43 +0200
> 
> But according to ISO 8601, should be formatted like this (see
> http://www.w3.org/TR/NOTE-datetime):
> 
> 2014-08-25T17:49:43+02:00

Yeah, it is not strictly ISO but more ISO-like (to further add
confusion, it is mostly RFC3339, which claims to be a "profile of
ISO8601". But we don't follow the timezone conventions there. Yeesh).

Interestingly, this actually came up when the feature was added:

  http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585

but there was some discussion of ISO8601's weird phrasing of "T" being
optional.

> I therefore suggest to adapt the output when using --date=iso or
> format:%ci to comply 100% with the ISO 8601 specs, or at least change
> documentation to say the output is only "ISO-like".

I think changing the output at this point would cause backwards
compatibility problems (not to mention that it's a lot less readable for
humans).

Patches welcome for a documentation update. I also think something like
--date=iso8601-strict might make sense for the case of feeding the
result to another parser.

-Peff

Re: Bug report: Author/Commit date in ISO 8601 format

[Oliver Busch]

Peff is right, I did not think of backwards compatibility issues. I 
believe a new option like "iso-strict" as he suggested will do the trick 
(and I'm probably not the only one to appreciate its implementation...).

Regards,

Oliver

Am 26.08.2014 um 15:06 schrieb Jeff King:
> On Tue, Aug 26, 2014 at 09:29:44AM +0200, Oliver Busch wrote:
>
>> I encountered the following problem: When using the date formatting option
>> ISO (either by setting --date=iso or using format:%ci for the committer
>> date), the output is formatted like this:
>>
>> 2014-08-25 17:49:43 +0200
>>
>> But according to ISO 8601, should be formatted like this (see
>> http://www.w3.org/TR/NOTE-datetime):
>>
>> 2014-08-25T17:49:43+02:00
> Yeah, it is not strictly ISO but more ISO-like (to further add
> confusion, it is mostly RFC3339, which claims to be a "profile of
> ISO8601". But we don't follow the timezone conventions there. Yeesh).
>
> Interestingly, this actually came up when the feature was added:
>
>    http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585
>
> but there was some discussion of ISO8601's weird phrasing of "T" being
> optional.
>
>> I therefore suggest to adapt the output when using --date=iso or
>> format:%ci to comply 100% with the ISO 8601 specs, or at least change
>> documentation to say the output is only "ISO-like".
> I think changing the output at this point would cause backwards
> compatibility problems (not to mention that it's a lot less readable for
> humans).
>
> Patches welcome for a documentation update. I also think something like
> --date=iso8601-strict might make sense for the case of feeding the
> result to another parser.
>
> -Peff
>


-- 

Oliver Busch, M.Eng.

Airport Research Center GmbH
Bismarckstraße 61
52066 Aachen
Germany

Phone: +49 241 16843-161
Fax: +49 241 16843-19
e-mail: Oliver.Busch@arc-aachen.de
Website: http://www.airport-consultants.com

Register Court: Amtsgericht Aachen HRB 7313
Ust-Id-No.: DE196450052

Managing Directors:
Dipl.-Ing. Tom Alexander Heuer

Re: Bug report: Author/Commit date in ISO 8601 format

[Oliver Busch]

PS: As far as I understand it, there is no "optionality" of the "T" as 
an indicator for the start of the time part.

Am 26.08.2014 um 15:06 schrieb Jeff King:
> On Tue, Aug 26, 2014 at 09:29:44AM +0200, Oliver Busch wrote:
>
>> I encountered the following problem: When using the date formatting option
>> ISO (either by setting --date=iso or using format:%ci for the committer
>> date), the output is formatted like this:
>>
>> 2014-08-25 17:49:43 +0200
>>
>> But according to ISO 8601, should be formatted like this (see
>> http://www.w3.org/TR/NOTE-datetime):
>>
>> 2014-08-25T17:49:43+02:00
> Yeah, it is not strictly ISO but more ISO-like (to further add
> confusion, it is mostly RFC3339, which claims to be a "profile of
> ISO8601". But we don't follow the timezone conventions there. Yeesh).
>
> Interestingly, this actually came up when the feature was added:
>
>    http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585
>
> but there was some discussion of ISO8601's weird phrasing of "T" being
> optional.
>
>> I therefore suggest to adapt the output when using --date=iso or
>> format:%ci to comply 100% with the ISO 8601 specs, or at least change
>> documentation to say the output is only "ISO-like".
> I think changing the output at this point would cause backwards
> compatibility problems (not to mention that it's a lot less readable for
> humans).
>
> Patches welcome for a documentation update. I also think something like
> --date=iso8601-strict might make sense for the case of feeding the
> result to another parser.
>
> -Peff
>


-- 

Oliver Busch, M.Eng.

Airport Research Center GmbH
Bismarckstraße 61
52066 Aachen
Germany

Phone: +49 241 16843-161
Fax: +49 241 16843-19
e-mail: Oliver.Busch@arc-aachen.de
Website: http://www.airport-consultants.com

Register Court: Amtsgericht Aachen HRB 7313
Ust-Id-No.: DE196450052

Managing Directors:
Dipl.-Ing. Tom Alexander Heuer

Re: Bug report: Author/Commit date in ISO 8601 format

[Jeff King]

On Tue, Aug 26, 2014 at 03:19:11PM +0200, Oliver Busch wrote:

> PS: As far as I understand it, there is no "optionality" of the "T" as an
> indicator for the start of the time part.

The standard says (and I am quoting from Wikipedia here, as I do not
have it myself):

  4.3.2 NOTE: By mutual agreement of the partners in information
  interchange, the character [T] may be omitted in applications where
  there is no risk of confusing a date and time of day representation
  with others defined in this International Standard.

But I am not sure that "omitted" means "can be replaced with a space".
And while you can define "by mutual agreement" as "git defines the
format, so any consumers agree to it" that is not necessarily useful to
somebody who wants to feed the result to an iso8601 parser that does not
know or care about git (i.e., it shoves the conversion work onto the
person in the middle).

-Peff

RE: Bug report: Author/Commit date in ISO 8601 format

[Jason Pyeron]

> -----Original Message-----
> From: Jeff King
> Sent: Tuesday, August 26, 2014 9:33
> 
> On Tue, Aug 26, 2014 at 03:19:11PM +0200, Oliver Busch wrote:
> 
> > PS: As far as I understand it, there is no "optionality" of 
> the "T" as an
> > indicator for the start of the time part.
> 
> The standard says (and I am quoting from Wikipedia here, as I do not
> have it myself):
> 
>   4.3.2 NOTE: By mutual agreement of the partners in information
>   interchange, the character [T] may be omitted in applications where
>   there is no risk of confusing a date and time of day representation
>   with others defined in this International Standard.

>From ISO 8601:2004

4.3.2 Complete representations
The time elements of a date and time of day expression shall be written in the following sequence.
a) For calendar dates:
year - month - day of the month - time designator - hour - minute - second - zone designator
b) For ordinal dates:
year - day of the year - time designator - hour - minute - second - zone designator
c) For week dates:
year - week designator - week - day of the week - time designator - hour - minute - second - zone
designator

The zone designator is empty if use is made of local time in accordance with 4.2.2.2 through 4.2.2.4, it is the
UTC designator [Z] if use is made of UTC of day in accordance with 4.2.4 and it is the difference-component if
use is made of local time and the difference from UTC in accordance with 4.2.5.2.
The character [T] shall be used as time designator to indicate the start of the representation of the time of day
component in these expressions. The hyphen [-] and the colon [:] shall be used, in accordance with 4.4.4, as
separators within the date and time of day expressions, respectively, when required.

NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in
applications where there is no risk of confusing a date and time of day representation with others defined in this
International Standard.

> 
> But I am not sure that "omitted" means "can be replaced with a space".
> And while you can define "by mutual agreement" as "git defines the
> format, so any consumers agree to it" that is not necessarily 
> useful to
> somebody who wants to feed the result to an iso8601 parser 
> that does not
> know or care about git (i.e., it shoves the conversion work onto the
> person in the middle).

Omitted /T?/ does not mean replaced with another character.

--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-                                                               -
- Jason Pyeron                      PD Inc. http://www.pdinc.us -
- Principal Consultant              10 West 24th Street #100    -
- +1 (443) 269-1555 x333            Baltimore, Maryland 21218   -
-                                                               -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.

Re: Bug report: Author/Commit date in ISO 8601 format

[Jeff King]

On Tue, Aug 26, 2014 at 10:10:33AM -0400, Jason Pyeron wrote:

> > But I am not sure that "omitted" means "can be replaced with a space".
> > And while you can define "by mutual agreement" as "git defines the
> > format, so any consumers agree to it" that is not necessarily 
> > useful to
> > somebody who wants to feed the result to an iso8601 parser 
> > that does not
> > know or care about git (i.e., it shoves the conversion work onto the
> > person in the middle).
> 
> Omitted /T?/ does not mean replaced with another character.

I would agree. But that is the argument made in the thread I linked
earlier.

I do not think there is much point in re-opening the argument, though.
Whatever git generates, changing the output would probably cause a lot
of pain.  We are likely better off adding a new, "real" iso8601 format
option (we can even deprecate the old one, or slate it for switching,
but we would need a notification period).

-Peff

Re: Bug report: Author/Commit date in ISO 8601 format

[Oliver Busch]

Am 26.08.2014 um 23:41 schrieb demerphq:
> On 26 August 2014 16:22, Jeff King <peff@peff.net 
> <mailto:peff@peff.net>> wrote:
>
>     On Tue, Aug 26, 2014 at 10:10:33AM -0400, Jason Pyeron wrote:
>
>     > > But I am not sure that "omitted" means "can be replaced with a
>     space".
>     > > And while you can define "by mutual agreement" as "git defines the
>     > > format, so any consumers agree to it" that is not necessarily
>     > > useful to
>     > > somebody who wants to feed the result to an iso8601 parser
>     > > that does not
>     > > know or care about git (i.e., it shoves the conversion work
>     onto the
>     > > person in the middle).
>     >
>     > Omitted /T?/ does not mean replaced with another character.
>
>     I would agree. But that is the argument made in the thread I linked
>     earlier.
>
>     I do not think there is much point in re-opening the argument, though.
>     Whatever git generates, changing the output would probably cause a lot
>     of pain.  We are likely better off adding a new, "real" iso8601 format
>     option (we can even deprecate the old one, or slate it for switching,
>     but we would need a notification period).
>
>
> Just curious but when was last time anyone other than the OP in this 
> thread saw an "iso" date/time stamp that had a "T"?
>
> I cant remember ever encountering such a system. I cant help but think 
> the OP should just $git_date=~s/ /T/ and move on to more interesting 
> things. I doubt there is any real value in truly supporting the spec 
> to the letter.  And the paucity of systems that do follow it makes me 
> think that is what most people think too.
>
> Yves
>
>
> -- 
> perl -Mre=debug -e "/just|another|perl|hacker/"

I do not think that this is a matter of how often you or I see an ISO 
date/time stamp with or without a "T". I agree that git's current output 
is the best solution for human readability, but it simply does not 
comply with the standard it claims to be compliant with, which in terms 
of machine readability IS a problem. Besides, it is not only the missing 
"T" (and I intentionally ignore the option of omitting it by mutual 
agreement here), but also the space character between time and timezone 
which should not be there and the missing colon in the timezone part.
And yes, I obviously can come around this issue by  refactoring the 
string myself which is not a very hard task, but, as Jeff already 
pointed out, this "shoves the conversion work onto the person in the 
middle" which I consider simply bad style.

Oliver

PS: On a personal note - if you needed to create software to make a 
living (as I do)  you would probably know that if one of your customers 
is reporting a problem, telling him to use a workaround and "move on to 
more interesting things" is considered bad style also. ;)

-- 

Oliver Busch, M.Eng.

Airport Research Center GmbH
Bismarckstraße 61
52066 Aachen
Germany

Phone: +49 241 16843-161
Fax: +49 241 16843-19
e-mail: Oliver.Busch@arc-aachen.de
Website: http://www.airport-consultants.com

Register Court: Amtsgericht Aachen HRB 7313
Ust-Id-No.: DE196450052

Managing Directors:
Dipl.-Ing. Tom Alexander Heuer