Re: ambiguous git-log date and timestamp syntax

[Jakub Narebski <jnareb@gmail.com>]

On Sat, 1 Mar 2008, Linus Torvalds wrote:
> On Sat, 1 Mar 2008, Jakub Narebski wrote:
> > > 
> > > From what I can tell it seems that dates can be specified relatively,
> > > e.g. "2 hours ago", or with any ISO 8601 or RFC 2822 date syntax. Is
> > > this correct, and are there any docs on specifying relative dates?
> > 
> > I don't know why git doesn't use getdate_r for this, instead rolling
> > out its own date parsing routines: approxidate*, parse_date. From what
> > I remember it should accept any date "date" (from coreutils) accepts,
> > but it does (from comments) for date to be in "C" locale.
> 
> strptime() and getdate() are totally unusable for any real date parsing 
> where you don't already know the exact format(s) of the string. And 
> neither of them can do any of the useful things that approxidate() does, 
> ie handle strings like "two months ago".
> 
> So yes, we do our own date parsing, where the "exact" format is the Unix 
> epoch timestamp (potentially together with explicit TZ information), but 
> we try to parse a wide variety of user-supplied strings that match any of 
> the standard formats (and do that loosely, so that when emails etc 
> invariably get things wrong and don't actually follow rfc2822 exactly, for 
> example, it still tries to make sense of it).

I wonder how it compares with GNU date (from GNU Corutils) inexact date
parsing (and why we couldn't lift the code from GNU date)... I guess that
main goal was to parse correctly "mail" dates, first.


BTW. Git has few other such "reimplementing the wheel" things, like strbuf,
or ALLOC_GROW, or it's own parseopt. I guess main reasons are to avoid
adding yet another dependency, and that existing solutions doesn't fill
all git needs.

-- 
Jakub Narebski
Poland