On Tue, 10 Jun 2008, Sverre Rabbelier wrote:
> On Tue, Jun 10, 2008 at 5:10 PM, Brandon Casey <casey@xxxxxxxxxxxxxxx> wrote:
> > Take a look at match_multi_number in date.c
> > European ordering is preferred when the separator is '.'
>
> Ok, then I'll use . in the future, that's nice :).
Well, there are safer ways to give the date.
If you do it in strict rfc822 format, you'll never have any confusion
what-so-ever. The "approxidate()" thing tries to parse any random input,
but it *is* meant to be excessively liberal.
IOW, you can literally say "at tea-time two weeks ago" and get a date, and
it will even work. But you can also say "my 3rd child was born in
December", and it will also give you a date. The date will not make
_sense_, but it will give you one (it will decide that what you meant
is "Dec 3rd").
So if you want to be precise and safe, you should be precise. I'd
personally suggest using yyyy-mm-dd, which is the ISO date format,
although if that fails approxidate will still try the admittedly
crazy yyyy-dd-mm.
And always set the timezone explicitly if you really care. Again, we try
out best if you don't explicitly say which timezone to use, but if you
don't want any guessing - even _informed_ guessing - you really should
state things explicitly.
> I think that it should bail out when it encounters "20-01-2008"
> instead of automagically going for european notation. Even more
> helpfull would be to inform the user that "20.01.2008" is the proper
> notation.
See above. git approxidate() tries the exact reverse: it's extremely
willing to turn absolutely any line noise into a date.
Which is really nice when you do
git log @{last.week}..
but if you actually want to state an exact date it really means that the
onus is on _you_ to be exact, and use a well-defined standard format.
Linus
--
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
