Re: [PATCH v2 0/1] MR1660: mstask: Don't assume a ONCE trigger is on the current day.

[Dmitry Timoshkov]

"Sven Baars (@sbaars)"  wrote:
> On Fri Dec  2 14:47:58 2022 +0000, **** wrote:
> > Dmitry Timoshkov replied on the mailing list:
> > "Sven Baars (@sbaars)" <[e-mail]> wrote:
> > > On Fri Dec  2 14:16:59 2022 +0000, **** wrote:
> > > > Dmitry Timoshkov replied on the mailing list:
> > > > \`\`\`
> > > > Sven Baars <[e-mail]> wrote:
> > > > > -                if (CompareFileTime(&begin_ft, &trigger_ft) <= 0 &&
> > > > CompareFileTime(&trigger_ft, &end_ft) < 0)
> > > > > +                if (CompareFileTime(&trigger_ft, &current_ft) >= 0)
> > > > >                  {
> > > > >                      if (!have_best_time ||
> > > > CompareFileTime(&trigger_ft, &best_ft) < 0)
> > > > >                      {
> > > > Removing the trigger end time check doesn't look right.
> > > > -- 
> > > > Dmitry.
> > > > \`\`\`
> > > Hi Dmitry,
> > > 
> > > Thanks for the reply. I don't see how begin_ft and end_ft are relevant
> > for this trigger. It happens exactly once, at the "Start" time and
> > "Begin" day. 
> > > 
> > > Having an "End" day before the "Begin" day is invalid for all
> > triggers. I could add a patch that checks for that.
> > Obviosuly the trigger shouldn't fire outside of begin/end time, so changing
> > the trigger time bounds check doesn't look right. At best, that should be
> > a separate patch with a bunch of tests.
> > -- 
> > Dmitry.
>
> I submitted a v2 that addresses your concern.

Looking at it again I don't understand the bounds check change. beging_ft already
accounts for current_ft earlier in the code. Can you leave it as it is now?