Am 26.08.2014 um 23:41 schrieb demerphq:
On 26 August 2014 16:22, Jeff King <p...@peff.net <mailto:p...@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.bu...@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

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to