{"thread":{"id":"37413","subject":"Bug report: Author/Commit date in ISO 8601 format","startedAt":"2014-08-26T07:29:44Z","lastAt":"2014-08-27T07:15:27Z","messageCount":8,"participants":["Oliver Busch","Jeff King","Jason Pyeron"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"248281","messageId":"53FC3768.3090905@arc-aachen.de","threadId":"37413","inReplyTo":null,"subject":"Bug report: Author/Commit date in ISO 8601 format","fromName":"Oliver Busch","fromEmail":"oliver.busch@arc-aachen.de","sentAt":"2014-08-26T07:29:44Z","receivedAt":"2014-08-26T07:29:44Z","isPatch":false,"sender":{"key":"oliver.busch@arc-aachen.de","avatar":null},"body":"Dear git community,\n\nI encountered the following problem: When using the date formatting \noption ISO (either by setting --date=iso or using format:%ci for the \ncommitter date), the output is formatted like this:\n\n2014-08-25 17:49:43 +0200\n\nBut according to ISO 8601, should be formatted like this (see \nhttp://www.w3.org/TR/NOTE-datetime):\n\n2014-08-25T17:49:43+02:00\n\nThis difference makes it impossible to use automated string conversion \n(in my case, I tried to use Delphi's XSBuildIns \n(http://wiert.me/2011/07/19/iso-8601-delphi-way-to-convert-xml-date-and-time-to-tdatetime-and-back-via-stack-overflow/), \nwhich converted git's output \"2014-08-25 17:49:43 +0200\" to a TDateTime \nof \"2014-08-25 02:00:00\"; conversion worked correctly when using \n\"2014-08-25T17:49:43+02:00\" as input).\n\nI therefore suggest to adapt the output when using --date=iso or \nformat:%ci to comply 100% with the ISO 8601 specs, or at least change \ndocumentation to say the output is only \"ISO-like\".\n\nKind regards,\n\nOliver Busch\n\n-- \n\nOliver Busch, M.Eng.\n\nAirport Research Center GmbH\nBismarckstraße 61\n52066 Aachen\nGermany\n\nPhone: +49 241 16843-161\nFax: +49 241 16843-19\ne-mail: Oliver.Busch@arc-aachen.de\nWebsite: http://www.airport-consultants.com\n\nRegister Court: Amtsgericht Aachen HRB 7313\nUst-Id-No.: DE196450052\n\nManaging Directors:\nDipl.-Ing. Tom Alexander Heuer\n"},{"id":"248302","messageId":"20140826130610.GG29180@peff.net","threadId":"37413","inReplyTo":"53FC3768.3090905@arc-aachen.de","subject":"Re: Bug report: Author/Commit date in ISO 8601 format","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-08-26T13:06:10Z","receivedAt":"2014-08-26T13:06:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2014 at 09:29:44AM +0200, Oliver Busch wrote:\n\n> I encountered the following problem: When using the date formatting option\n> ISO (either by setting --date=iso or using format:%ci for the committer\n> date), the output is formatted like this:\n> \n> 2014-08-25 17:49:43 +0200\n> \n> But according to ISO 8601, should be formatted like this (see\n> http://www.w3.org/TR/NOTE-datetime):\n> \n> 2014-08-25T17:49:43+02:00\n\nYeah, it is not strictly ISO but more ISO-like (to further add\nconfusion, it is mostly RFC3339, which claims to be a \"profile of\nISO8601\". But we don't follow the timezone conventions there. Yeesh).\n\nInterestingly, this actually came up when the feature was added:\n\n http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585\n\nbut there was some discussion of ISO8601's weird phrasing of \"T\" being\noptional.\n\n> I therefore suggest to adapt the output when using --date=iso or\n> format:%ci to comply 100% with the ISO 8601 specs, or at least change\n> documentation to say the output is only \"ISO-like\".\n\nI think changing the output at this point would cause backwards\ncompatibility problems (not to mention that it's a lot less readable for\nhumans).\n\nPatches welcome for a documentation update. I also think something like\n--date=iso8601-strict might make sense for the case of feeding the\nresult to another parser.\n\n-Peff\n"},{"id":"248303","messageId":"53FC8843.3030309@arc-aachen.de","threadId":"37413","inReplyTo":"20140826130610.GG29180@peff.net","subject":"Re: Bug report: Author/Commit date in ISO 8601 format","fromName":"Oliver Busch","fromEmail":"oliver.busch@arc-aachen.de","sentAt":"2014-08-26T13:14:43Z","receivedAt":"2014-08-26T13:14:43Z","isPatch":false,"sender":{"key":"oliver.busch@arc-aachen.de","avatar":null},"body":"Peff is right, I did not think of backwards compatibility issues. I \nbelieve a new option like \"iso-strict\" as he suggested will do the trick \n(and I'm probably not the only one to appreciate its implementation...).\n\nRegards,\n\nOliver\n\nAm 26.08.2014 um 15:06 schrieb Jeff King:\n> On Tue, Aug 26, 2014 at 09:29:44AM +0200, Oliver Busch wrote:\n>\n>> I encountered the following problem: When using the date formatting option\n>> ISO (either by setting --date=iso or using format:%ci for the committer\n>> date), the output is formatted like this:\n>>\n>> 2014-08-25 17:49:43 +0200\n>>\n>> But according to ISO 8601, should be formatted like this (see\n>> http://www.w3.org/TR/NOTE-datetime):\n>>\n>> 2014-08-25T17:49:43+02:00\n> Yeah, it is not strictly ISO but more ISO-like (to further add\n> confusion, it is mostly RFC3339, which claims to be a \"profile of\n> ISO8601\". But we don't follow the timezone conventions there. Yeesh).\n>\n> Interestingly, this actually came up when the feature was added:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585\n>\n> but there was some discussion of ISO8601's weird phrasing of \"T\" being\n> optional.\n>\n>> I therefore suggest to adapt the output when using --date=iso or\n>> format:%ci to comply 100% with the ISO 8601 specs, or at least change\n>> documentation to say the output is only \"ISO-like\".\n> I think changing the output at this point would cause backwards\n> compatibility problems (not to mention that it's a lot less readable for\n> humans).\n>\n> Patches welcome for a documentation update. I also think something like\n> --date=iso8601-strict might make sense for the case of feeding the\n> result to another parser.\n>\n> -Peff\n>\n\n\n-- \n\nOliver Busch, M.Eng.\n\nAirport Research Center GmbH\nBismarckstraße 61\n52066 Aachen\nGermany\n\nPhone: +49 241 16843-161\nFax: +49 241 16843-19\ne-mail: Oliver.Busch@arc-aachen.de\nWebsite: http://www.airport-consultants.com\n\nRegister Court: Amtsgericht Aachen HRB 7313\nUst-Id-No.: DE196450052\n\nManaging Directors:\nDipl.-Ing. Tom Alexander Heuer\n"},{"id":"248304","messageId":"53FC894F.9060402@arc-aachen.de","threadId":"37413","inReplyTo":"20140826130610.GG29180@peff.net","subject":"Re: Bug report: Author/Commit date in ISO 8601 format","fromName":"Oliver Busch","fromEmail":"oliver.busch@arc-aachen.de","sentAt":"2014-08-26T13:19:11Z","receivedAt":"2014-08-26T13:19:11Z","isPatch":false,"sender":{"key":"oliver.busch@arc-aachen.de","avatar":null},"body":"PS: As far as I understand it, there is no \"optionality\" of the \"T\" as \nan indicator for the start of the time part.\n\nAm 26.08.2014 um 15:06 schrieb Jeff King:\n> On Tue, Aug 26, 2014 at 09:29:44AM +0200, Oliver Busch wrote:\n>\n>> I encountered the following problem: When using the date formatting option\n>> ISO (either by setting --date=iso or using format:%ci for the committer\n>> date), the output is formatted like this:\n>>\n>> 2014-08-25 17:49:43 +0200\n>>\n>> But according to ISO 8601, should be formatted like this (see\n>> http://www.w3.org/TR/NOTE-datetime):\n>>\n>> 2014-08-25T17:49:43+02:00\n> Yeah, it is not strictly ISO but more ISO-like (to further add\n> confusion, it is mostly RFC3339, which claims to be a \"profile of\n> ISO8601\". But we don't follow the timezone conventions there. Yeesh).\n>\n> Interestingly, this actually came up when the feature was added:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/52414/focus=52585\n>\n> but there was some discussion of ISO8601's weird phrasing of \"T\" being\n> optional.\n>\n>> I therefore suggest to adapt the output when using --date=iso or\n>> format:%ci to comply 100% with the ISO 8601 specs, or at least change\n>> documentation to say the output is only \"ISO-like\".\n> I think changing the output at this point would cause backwards\n> compatibility problems (not to mention that it's a lot less readable for\n> humans).\n>\n> Patches welcome for a documentation update. I also think something like\n> --date=iso8601-strict might make sense for the case of feeding the\n> result to another parser.\n>\n> -Peff\n>\n\n\n-- \n\nOliver Busch, M.Eng.\n\nAirport Research Center GmbH\nBismarckstraße 61\n52066 Aachen\nGermany\n\nPhone: +49 241 16843-161\nFax: +49 241 16843-19\ne-mail: Oliver.Busch@arc-aachen.de\nWebsite: http://www.airport-consultants.com\n\nRegister Court: Amtsgericht Aachen HRB 7313\nUst-Id-No.: DE196450052\n\nManaging Directors:\nDipl.-Ing. Tom Alexander Heuer\n"},{"id":"248305","messageId":"20140826133326.GA30887@peff.net","threadId":"37413","inReplyTo":"53FC894F.9060402@arc-aachen.de","subject":"Re: Bug report: Author/Commit date in ISO 8601 format","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-08-26T13:33:26Z","receivedAt":"2014-08-26T13:33:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2014 at 03:19:11PM +0200, Oliver Busch wrote:\n\n> PS: As far as I understand it, there is no \"optionality\" of the \"T\" as an\n> indicator for the start of the time part.\n\nThe standard says (and I am quoting from Wikipedia here, as I do not\nhave it myself):\n\n 4.3.2 NOTE: By mutual agreement of the partners in information\n interchange, the character [T] may be omitted in applications where\n there is no risk of confusing a date and time of day representation\n with others defined in this International Standard.\n\nBut I am not sure that \"omitted\" means \"can be replaced with a space\".\nAnd while you can define \"by mutual agreement\" as \"git defines the\nformat, so any consumers agree to it\" that is not necessarily useful to\nsomebody who wants to feed the result to an iso8601 parser that does not\nknow or care about git (i.e., it shoves the conversion work onto the\nperson in the middle).\n\n-Peff\n"},{"id":"248306","messageId":"F8DE5B94F596455FA56956B8A865EC73@black","threadId":"37413","inReplyTo":"20140826133326.GA30887@peff.net","subject":"RE: Bug report: Author/Commit date in ISO 8601 format","fromName":"Jason Pyeron","fromEmail":"jpyeron@pdinc.us","sentAt":"2014-08-26T14:10:33Z","receivedAt":"2014-08-26T14:10:33Z","isPatch":false,"sender":{"key":"jpyeron@pdinc.us","avatar":"https://gravatar.com/avatar/c2e53452caa53d940768a1ffc9cf76196d851b9b534b7a39cd39852a70a0508f?d=mp&s=160"},"body":"> -----Original Message-----\n> From: Jeff King\n> Sent: Tuesday, August 26, 2014 9:33\n> \n> On Tue, Aug 26, 2014 at 03:19:11PM +0200, Oliver Busch wrote:\n> \n> > PS: As far as I understand it, there is no \"optionality\" of \n> the \"T\" as an\n> > indicator for the start of the time part.\n> \n> The standard says (and I am quoting from Wikipedia here, as I do not\n> have it myself):\n> \n> 4.3.2 NOTE: By mutual agreement of the partners in information\n> interchange, the character [T] may be omitted in applications where\n> there is no risk of confusing a date and time of day representation\n> with others defined in this International Standard.\n\n>From ISO 8601:2004\n\n4.3.2 Complete representations\nThe time elements of a date and time of day expression shall be written in the following sequence.\na) For calendar dates:\nyear - month - day of the month - time designator - hour - minute - second - zone designator\nb) For ordinal dates:\nyear - day of the year - time designator - hour - minute - second - zone designator\nc) For week dates:\nyear - week designator - week - day of the week - time designator - hour - minute - second - zone\ndesignator\n\nThe 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\nUTC designator [Z] if use is made of UTC of day in accordance with 4.2.4 and it is the difference-component if\nuse is made of local time and the difference from UTC in accordance with 4.2.5.2.\nThe character [T] shall be used as time designator to indicate the start of the representation of the time of day\ncomponent in these expressions. The hyphen [-] and the colon [:] shall be used, in accordance with 4.4.4, as\nseparators within the date and time of day expressions, respectively, when required.\n\nNOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in\napplications where there is no risk of confusing a date and time of day representation with others defined in this\nInternational Standard.\n\n> \n> But I am not sure that \"omitted\" means \"can be replaced with a space\".\n> And while you can define \"by mutual agreement\" as \"git defines the\n> format, so any consumers agree to it\" that is not necessarily \n> useful to\n> somebody who wants to feed the result to an iso8601 parser \n> that does not\n> know or care about git (i.e., it shoves the conversion work onto the\n> person in the middle).\n\nOmitted /T?/ does not mean replaced with another character.\n\n--\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\n- -\n- Jason Pyeron PD Inc. http://www.pdinc.us -\n- Principal Consultant 10 West 24th Street #100 -\n- +1 (443) 269-1555 x333 Baltimore, Maryland 21218 -\n- -\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-\nThis message is copyright PD Inc, subject to license 20080407P00.\n"},{"id":"248308","messageId":"20140826142203.GA31205@peff.net","threadId":"37413","inReplyTo":"F8DE5B94F596455FA56956B8A865EC73@black","subject":"Re: Bug report: Author/Commit date in ISO 8601 format","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-08-26T14:22:03Z","receivedAt":"2014-08-26T14:22:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Aug 26, 2014 at 10:10:33AM -0400, Jason Pyeron wrote:\n\n> > But I am not sure that \"omitted\" means \"can be replaced with a space\".\n> > And while you can define \"by mutual agreement\" as \"git defines the\n> > format, so any consumers agree to it\" that is not necessarily \n> > useful to\n> > somebody who wants to feed the result to an iso8601 parser \n> > that does not\n> > know or care about git (i.e., it shoves the conversion work onto the\n> > person in the middle).\n> \n> Omitted /T?/ does not mean replaced with another character.\n\nI would agree. But that is the argument made in the thread I linked\nearlier.\n\nI do not think there is much point in re-opening the argument, though.\nWhatever git generates, changing the output would probably cause a lot\nof pain. We are likely better off adding a new, \"real\" iso8601 format\noption (we can even deprecate the old one, or slate it for switching,\nbut we would need a notification period).\n\n-Peff\n"},{"id":"248383","messageId":"53FD858F.7050409@arc-aachen.de","threadId":"37413","inReplyTo":"CANgJU+UifjMJPcmC28-SrZOEUR45qQQfdM_rf-HHtkfBAMEyRw@mail.gmail.com","subject":"Re: Bug report: Author/Commit date in ISO 8601 format","fromName":"Oliver Busch","fromEmail":"oliver.busch@arc-aachen.de","sentAt":"2014-08-27T07:15:27Z","receivedAt":"2014-08-27T07:15:27Z","isPatch":false,"sender":{"key":"oliver.busch@arc-aachen.de","avatar":null},"body":"Am 26.08.2014 um 23:41 schrieb demerphq:\n> On 26 August 2014 16:22, Jeff King > wrote:\n>\n> On Tue, Aug 26, 2014 at 10:10:33AM -0400, Jason Pyeron wrote:\n>\n> > > But I am not sure that \"omitted\" means \"can be replaced with a\n> space\".\n> > > And while you can define \"by mutual agreement\" as \"git defines the\n> > > format, so any consumers agree to it\" that is not necessarily\n> > > useful to\n> > > somebody who wants to feed the result to an iso8601 parser\n> > > that does not\n> > > know or care about git (i.e., it shoves the conversion work\n> onto the\n> > > person in the middle).\n> >\n> > Omitted /T?/ does not mean replaced with another character.\n>\n> I would agree. But that is the argument made in the thread I linked\n> earlier.\n>\n> I do not think there is much point in re-opening the argument, though.\n> Whatever git generates, changing the output would probably cause a lot\n> of pain. We are likely better off adding a new, \"real\" iso8601 format\n> option (we can even deprecate the old one, or slate it for switching,\n> but we would need a notification period).\n>\n>\n> Just curious but when was last time anyone other than the OP in this \n> thread saw an \"iso\" date/time stamp that had a \"T\"?\n>\n> I cant remember ever encountering such a system. I cant help but think \n> the OP should just $git_date=~s/ /T/ and move on to more interesting \n> things. I doubt there is any real value in truly supporting the spec \n> to the letter. And the paucity of systems that do follow it makes me \n> think that is what most people think too.\n>\n> Yves\n>\n>\n> -- \n> perl -Mre=debug -e \"/just|another|perl|hacker/\"\n\nI do not think that this is a matter of how often you or I see an ISO \ndate/time stamp with or without a \"T\". I agree that git's current output \nis the best solution for human readability, but it simply does not \ncomply with the standard it claims to be compliant with, which in terms \nof machine readability IS a problem. Besides, it is not only the missing \n\"T\" (and I intentionally ignore the option of omitting it by mutual \nagreement here), but also the space character between time and timezone \nwhich should not be there and the missing colon in the timezone part.\nAnd yes, I obviously can come around this issue by refactoring the \nstring myself which is not a very hard task, but, as Jeff already \npointed out, this \"shoves the conversion work onto the person in the \nmiddle\" which I consider simply bad style.\n\nOliver\n\nPS: On a personal note - if you needed to create software to make a \nliving (as I do) you would probably know that if one of your customers \nis reporting a problem, telling him to use a workaround and \"move on to \nmore interesting things\" is considered bad style also. ;)\n\n-- \n\nOliver Busch, M.Eng.\n\nAirport Research Center GmbH\nBismarckstraße 61\n52066 Aachen\nGermany\n\nPhone: +49 241 16843-161\nFax: +49 241 16843-19\ne-mail: Oliver.Busch@arc-aachen.de\nWebsite: http://www.airport-consultants.com\n\nRegister Court: Amtsgericht Aachen HRB 7313\nUst-Id-No.: DE196450052\n\nManaging Directors:\nDipl.-Ing. Tom Alexander Heuer\n"}]}