Bug report: Author/Commit date in ISO 8601 format

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

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

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 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

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:

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 03:19:11PM +0200, Oliver Busch wrote:

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

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.

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.

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

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

Am 26.08.2014 um 23:41 schrieb demerphq:

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. ;)