Re: Date parsing

> 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.