Am 26.08.2014 um 23:41 schrieb demerphq:
On 26 August 2014 16:22, Jeff King <peff@xxxxxxxx
<mailto:peff@xxxxxxxx>> 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@xxxxxxxxxxxxx
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html