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

[Tim Chase]

On 2023-09-08 18:19, Dianne Skoll via Remind-fans wrote:
> In theory, any baseyr() after 1900 where January 1st is a Monday should
> work. But in practice, I bet a bunch of assumptions that I made and
> didn't think about will mean breakage.

Thanks for the hints.  I figured it was mostly okay, though also
was unsure whether there was any *future* date rendering caps, e.g.
remind working for 100 years and 1990-2090 was a reasonable range,
where, if set to 1900, I'd end up with 1900-2000 and things might
break after that.  Reading src/custom.h, it looks like that allowable
range is 4000 years which is more than enough time to not be my
problem when it rolls over, whether it starts at 1990 or 1906. :-P

> If you want to try it, potential baseyrs up to 1990 are:
> 
> 1906, 1912, 1917, 1923, 1934, 1940, 1945,
> 1951, 1962, 1968, 1973, 1979, 1990.

Helpful to know where the fragile points might be and how to make
less problem-prone choices.

> Interestingly, no year in the 1980s starts on a Monday.  Huh! :)

So unusual, I checked it too, and indeed:

  # check for starting on a Tues? twice
  $ for y in {1980..1989} ; do cal 1 $y ; done | grep -B2 ' 5 *$'
      January 1980      
  Su Mo Tu We Th Fr Sa  
         1  2  3  4  5  
  --
      January 1985      
  Su Mo Tu We Th Fr Sa  
         1  2  3  4  5  

  # check for starting on a Mon? no results
  $ for y in {1980..1989} ; do cal 1 $y ; done | grep -B2 ' 6 *$'
  $

> > As an added hope, I'd love to be able to specify a partial date
> > (the year here) in the FROM and have it take the rest of it from
> > the base date specification, something like
> 
> >   REM Jul 13 FROM 1976 MSG Joe's birthday [age()]
> >   REM Aug 23 FROM 1972 MSG Mom & Dad [age()]
> 
> Nope, don't like it.  Won't happen. :)

Even if I hand you a 4-line patch? :puppy-eyes:

  $ git diff
  diff --git a/src/dorem.c b/src/dorem.c
  index 45dde86..d1d74d8 100644
  --- a/src/dorem.c
  +++ b/src/dorem.c
  @@ -866,6 +866,10 @@ static int ParseScanFrom(ParsePtr s, Trigger *t, int type)
              break;
   
          default:
  +           if (y != NO_YR && (m == NO_MON || d == NO_DAY)) {
  +               m = t->m;
  +               d = t->d;
  +           }
              if (y == NO_YR || m == NO_MON || d == NO_DAY) {
                  Eprint("%s: %s", word, ErrMsg[E_INCOMPLETE]);
                  DBufFree(&buf);

I can also cobble together some doc patches and possibly a test-case
if you would like those, too.  I tested it with insufficient
information to populate the FROM 

  REM Sep FROM 2022 MSG Just month fails
  REM 11 FROM 2022 MSG Just day fails

which still appropriately gives the "incomplete date specification",
and with my use-case:

  REM Sep 11 FROM 2001 MSG [trigfrom()] Rememberance day

  $ rem 2000-9-11 # nothing, too early
  $ rem 2023-9-11 # gives reminder as expected

and [year(trigfrom())] works as I'd hope.

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

> I don't see how:
> 
>     REM Jul 13 FROM 1976 MSG Joe's birthday [age()]
> 
> is any better than:
> 
>     REM Jul 13 MSG Joe's birthday [age(1976)]

The main reason I attemtped it was to get the FROM for certain
events, initially brought to my attention by putting friends' pending
wedding on the calendar a year out and having it show up before the
actual event, e.g.:

  REM Sep 9 [frm(2024)] MSG Romeo & Juliet's wedding [anniv()]

With the modifications, it doesn't show up today because of the
resulting FROM.

Originally I had used an age()-type function like you suggest, 

  REM Sep 9 MSG Romeo & Juliet's wedding [anniv(2024)]

but in this case it gave me

  Romeo & Juliet's wedding (-1st)

so I set out to exercise (coughabusecough) remind expressions to
see what I could do.

> And I bet it'll be *way* faster than your hacks.

That is indisputably the case :-)

It was mostly a proof-of-concept experiment.  Since my reminder
files are tracked in git, it wouldn't be too onerous to revert that
changeset back to using the "age()" with the date explicitly.

Thanks for the thoughts!

-tkc