RE: [Bug] worktree prune --expires

["Randall S. Becker" <rsbecker@nexbridge.com>]

On March 30, 2021 5:10 PM, Junio C Hamano wrote:
> To: Randall S. Becker <rsbecker@nexbridge.com>
> Cc: git@vger.kernel.org
> Subject: Re: [Bug] worktree prune --expires
> 
> "Randall S. Becker" <rsbecker@nexbridge.com> writes:
> 
> > This is pretty much just a quibble, but the command parser for
> > worktree prune --expires should really report when a timestamp is
> > invalid. For
> > example:
> >
> > worktree prune --expires A:30 actually
> 
> Assuming that you had "git" in front, and spelled "--expire" without the
extra
> 's':

Yes, it was. I just transcribed it badly.

> $ git worktree prune --expire no.such.date
> fatal: malformed expiration date 'no.such.date'
> 
> So apparently, "A:30" is taken as a expiration date that is not malformed.
> 
> $ git rev-parse --since=A:30 --until=now
> --max-age=1617138312
> --min-age=1617138312
> 
> Appears to show that A:30 is interpreted as the same as 'now', but thta is
an
> unlucky coincidence of the day.
> 
> What happens in this case is that "A:" is discarded as cruft (just like
dots are
> discarded in "git log --since=8.days.ago"), and only the "30" takes effect
of
> filling an unspecified "date of the month"
> [*1*].  And then the remainder is taken from the wallclock time, and that
is
> how the above "rev-parse" shows the same for A:30 and now, as it is the
> 30th of the month for me right now.
> 
> $ git rev-parse --since=A:31 --until=now
> --max-age=1617224881
> --min-age=1617138481
> 
> gives me the same time tomorrow (for the same reason that today's 30th for
> me).
> 
> 
> [Footnote]
> 
> *1* In A:30, there is no "date of month", "month", "year", etc. specified,
so
> we start from all unspecified, take the first number that is discovered
(i.e. 30)
> and fill "date of the month"
> with it.

Well, sounds a bit like an elbow test situation. The question is, what to do
about it, if anything, I suppose. I didn't even put the "30" in context
while testing. Oops.