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