Honestly, I think you should practice that trimming a bit more.
On one hand, the code you posted is not a short, self-contained, compilable example; not even if you combine it with Inform Example 374, “Nine AM Appointment”, since, as you note, it won’t compile without the day and month definitions.
On the other hand, it turns out that most of your code is not needed to trigger the bug. In fact, only the following lines, appended to Example 374, are needed:
When play begins: now the time of day is 11:59 PM.
Test bug with "wait 2 minutes".
Anyway, it turns out to be a bug in the example, and/or in Inform: the “carry out waiting more” doesn’t use the special time arithmetic phrases “(interval) after/before (time)” that wrap the clock around correctly, so any waiting period that skips over 12:00 AM will cause the rule to enter an infinite loop. You can fix it by replacing the “carry out waiting” rule with the following:
Carry out waiting more:
let the time interval be the time understood minus one minute;
let the target time be the time interval after the time of day; [<-- this wraps around correctly]
while the time of day is not the target time:
follow the turn sequence rules.
You may also want to add a rule to block waiting for zero minutes, which the rule above would treat as a 24-hour wait:
Check waiting more:
if the time understood is less than one minute, say "Feeling a bit impatient, are we?" instead.
(And yes, I really should report this as a bug in the example, except that I don’t have my password for the Inform bug tracker saved on this computer, and I can’t seem to remember it myself. Later, I guess.)
Ps. I can’t test it for the reason you noted yourself, but this line in the code you posted above looks funny:
You might want to check exactly what Inform is resolving that “last” to; it might not be what you expect.