Skip to content
  • Jeff King's avatar
    approxidate: allow ISO-like dates far in the future · d3723953
    Jeff King authored and Junio C Hamano's avatar Junio C Hamano committed
    When we are parsing approxidate strings and we find three
    numbers separate by one of ":/-.", we guess that it may be a
    date. We feed the numbers to match_multi_number, which
    checks whether it makes sense as a date in various orderings
    (e.g., dd/mm/yy or mm/dd/yy, etc).
    
    One of the checks we do is to see whether it is a date more
    than 10 days in the future. This was added in 38035cf4 (date
    parsing: be friendlier to our European friends.,
    2006-04-05), and lets us guess that if it is currently April
    2014, then "10/03/2014" is probably March 10th, not October
    3rd.
    
    This has a downside, though; if you want to be overly
    generous with your "--until" date specification, we may
    wrongly parse "2014-12-01" as "2014-01-12" (because the
    latter is an in-the-past date). If the year is a future year
    (i.e., both are future dates), it gets even weirder. Due to
    the vagaries of approxidate, months _after_ the current date
    (no matter the year) get flipped, but ones before do not.
    
    This patch drops the "in the future" check for dates of this
    form, letting us treat them always as yyyy-mm-dd, even if
    they are in the future. This does not affect the normal
    dd/mm/yyyy versus mm/dd/yyyy lookup, because this code path
    only kicks in when the first number is greater than 70
    (i.e., it must be a year, and cannot be either a date or a
    month).
    
    The one possible casualty is that "yyyy-dd-mm" is less
    likely to be chosen over "yyyy-mm-dd". That's probably OK,
    though because:
    
      1. The difference happens only when the date is in the
         future. Already we prefer yyyy-mm-dd for dates in the
         past.
    
      2. It's unclear whether anybody even uses yyyy-dd-mm
         regularly. It does not appear in lists of common date
         formats in Wikipedia[1,2].
    
      3. Even if (2) is wrong, it is better to prefer ISO-like
         dates, as that is consistent with what we use elsewhere
         in git.
    
    [1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country
    [2] http://en.wikipedia.org/wiki/Calendar_date
    
    
    
    Signed-off-by: default avatarJeff King <peff@peff.net>
    Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
    d3723953