[Remind-Fans] Issues with changing baseyr()? And partial FROM specification?

[Tim Chase]

On 2023-09-09 09:09, Dianne Skoll via Remind-fans wrote:
> On Sat, 9 Sep 2023 08:04:35 -0500
> > Even if I hand you a 4-line patch? :puppy-eyes:
> 
> Nope.  The patch is incorrect and will break in a number of situations.
> For example:
> 
>     REM 13 FROM 1992 MSG foo

The patch only auto-completes the FROM if the FROM has the year and
the reminder date-spec has both the month and the day.  From my
earlier email:

TC> It'd be possible to make that code uglier to accommodate various
TC> permuations of missing-bits, but the year-only case is what I find
TC> myself wanting the most.

so the patch doesn't so much break as exhibit the existing "Incomplete
date specification" behavior:

  $ cat test_partial_incomplete
  REM 13 FROM 1992 MSG foo

  $ cat test_partial_year
  REM Jul 13 FROM 1992 MSG foo

  $ git reset --hard HEAD # your upstream
  $ make
  $ src/remind -n -f test_partial_incomplete
  test_partial_incomplete(1): FROM: Incomplete date specification
  $ src/remind -n -f test_partial_year
  test_partial_incomplete(1): FROM: Incomplete date specification

  $ git stash apply # apply my patch
  $ make
  $ src/remind -n -f test_partial_incomplete
  test_partial_incomplete(1): FROM: Incomplete date specification
  $ src/remind -n -f test_partial_year
  2024/07/13 foo

> It's also not clear to me why you'd want to auto-complete FROM in the
> first example as 1976-07-13 as opposed to 1976-01-01; I would argue the
> latter makes more sense.

In my annual-only use-case, they should work out to the same thing.
There are no other Jul 13 between 1976-01-01 and 1976-7-13. ;-)
So if YYYY-01-01 is more palatable, it shouldn't change anything.

> Anyway... nope, won't happen.  FROM will always require a complete date
> specification.

Ah, well.  I tried.

Thanks for your thoughts,

-tim