Re: [RFC/PATCH] date parsing: be friendlier to our European friends.

From: Junio C Hamano <junkio@cox.net>
Date: Apr 5, 2006, 22:54 UTC
Message-ID: <7vhd57zl9x.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <7vlkujzly0.fsf_-_@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> writes:

Show 15 quoted lines

> This does three things, only applies to cases where the user
> manually tries to override the author/commit time by environment
> variables, with non-ISO, non-2822 format date-string:
>
>  - Refuses to use the interpretation to put the date in the
>    future; recent kernel history has a commit made with
>    10/03/2006 which is recorded as October 3rd.
>
>  - Adds '.' as the possible year-month-date separator.  We
>    learned from our European friends on the #git channel that
>    dd.mm.yyyy is the norm there.
>
>  - When the separator is '.', we prefer dd.mm.yyyy over
>    mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
>    dd/mm/yy[yy].

Before the list gets useless comments, the code prefer to accept more sensible and/or unambiguous forms, such as ISO or RFC2822. The issue this addresses is what to do when we get other forms.