Re: Date parsing

[Linus Torvalds <torvalds@linux-foundation.org>]

On Tue, 10 Jun 2008, Sverre Rabbelier wrote:
> On Tue, Jun 10, 2008 at 5:10 PM, Brandon Casey <casey@nrlssc.navy.mil> 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