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

[Oliver Busch <oliver.busch@arc-aachen.de>]

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