GitoxideLabs/gitoxide gix-date-v0.16.0

gix-date v0.16.0

on GitHub

Bug Fixes

• relative dates roll over month ends like Git, instead of clamping.
  N months/years ago now steps down the calendar fields while keeping the
  day-of-month, so a day beyond the end of the target month rolls over into
  the following month, the way mktime(3) normalizes it for Git: one month
  before 2026-03-31 now is 2026-03-03, no longer 2026-02-28.

  Count-unit pairs also apply in input order and accumulate when repeated,
  both matching Git as well.

• accept the relative dates Git accepts, and read their units case-insensitively.
  Five shapes approxidate() in Git's date.c accepts were not accepted here.

  Units are now matched without regard to case, as match_string() does. This one
  produced a wrong answer rather than a rejection: 2 HOURS ago fell through to
  the catch-all and became two seconds ago, which looks like a date rather than
  an error.

  More than one <count> <unit> pair is read, so 2 days 3 hours ago is both of
  them. Git applies a unit the moment it sees one and carries on, and stopping
  after the first pair would substitute a plausible-looking two days.

  Any byte that is neither a digit nor a letter separates the parts, because
  approxidate_alpha() ends a word at the first byte that is not a letter. So
  1.hour.ago and 1-hour-ago read as 1 hour ago does, and a leading - is a
  separator too, which is why -1 days ago is one day rather than a rejection.
  Note this holds for the <count> <unit> shapes handled here; approxidate_digit()
  does look at the byte after a digit run, which is how 2008.12.24 stays a date.

  Counts may be spelled out, from one to ten, as they are in number_name[].
  zero is not among them, since Git's lookup starts at one. last is a count of
  one, so last week resolves.

  The trailing ago is not required, because Git applies a unit as soon as it sees
  one; even 2 days hence resolves into the past there. It is still what permits an
  unknown unit to count as seconds, though, or 1745582210 +0200 would parse as a
  count in the unknown unit 0200 and never reach parse_raw().

  Seven entries are added to the baseline, so these record Git's own answers. The
  comment claiming Git reads an unknown unit as seconds is corrected: it does not,
  and leaves the count pending, where it stands in for a field of the date itself.

  Not addressed: noon, midnight, tea, AM and PM are in Git's special[]
  table and still rejected here. They resolve against the local time zone, and this
  parser deliberately works in UTC.

• accept the '@' prefix on epoch dates, like Git does
  parse() is documented as parsing any time that Git can parse, and @ is the
  one prefix Git checks before anything else in parse_date_basic(). Two paths
  reach a timestamp there: @<seconds> ±HHMM is taken by that fast path for any
  value, while a bare @<seconds> is skipped as an unmatched byte and recognised
  only by the epoch heuristic that starts at 100000000.

  Both forms were rejected here even though the underlying 1660874655 +0800 and
  1234567890 formats already parse, so the prefix is stripped and those parsers
  reused.

  Also corrects the relative-date documentation, which advertised 1 hour from now although only now, today, yesterday and <n> <unit> ago are
  understood.

Bug Fixes (BREAKING)

• represent now in parse(... ,now) as timezone-aware instant.
  This allows time computation to be timezone aware, just like in Git.

Commit Statistics

• 12 commits contributed to the release over the course of 38 calendar days.
• 38 days passed between releases.
• 4 commits were understood as conventional.
• 1 unique issue was worked on: #2909

Commit Details