- - - -
"time of day" = time: 12:00 pm
"whether or not the time of day is 12:00 am" = truth state: false
"whether or not the time of day is 12:00 pm" = truth state: false
- - - -

where

- - - -
"time of day" = time: 12:00 am
"whether or not the time of day is 12:00 am" = truth state: true
"whether or not the time of day is 12:00 pm" = truth state: false
- - - -

was expected. The generated I6 is just

- - - -
the_time = (the_time+1) ;
- - - -

so wraparound is every 2^32 minutes rather than every 1440.

Minimal Source Text To Reproduce

There is a room.
When play begins:
now the time of day is 11:59 pm;
now the time of day is the time of day plus one minute; [imitating the Slow Room snippet in WI 9.8]
[increment the time of day;] [alternate syntax]
showme the time of day;
showme whether or not the time of day is 12:00 am;
showme whether or not the time of day is 12:00 pm.

There are special phrases for time computation that avoid this problem:

To decide which time is (t - time) before (t2 - time): ...
To decide which time is (t - time) after (t2 - time): ...

If you change the computation to "now the time of day is one minute after the time of day", the example works correctly.

Generic value computation ("increment", "plus") should be special-cased for time values -- either to throw an error, or do the right thing (modulo 1440). If it throws an error, the documentation should talk about this.

It might make sense to sidestep the problem by separating the kinds for duration and time, concepts that Inform currently conflates. Durations make sense as full-fledged arithmetic values and don't need this special casing (which only serves to add caveats to WI 9.8), whereas times do need to be reduced modulo 1440m and can't sensibly participate in arithmetic expressions except to be increased or decreased by a duration, operations that can be supported by overloading the appropriate phrases.

I took a conscious decision early on to simplify things by not requiring users to differentiate between absolute and relative times, so here we are. I've instead made the compiler renormalise all times to the range 0 to 1439 after all arithmetic operations are performed on them.