I would treat the changed expectation as a claim about the specification, then ask what independent evidence supports it. For the invoice timezone example, a fixed instant, explicit business timezone and expected calendar date provide a clearer oracle than the output produced by the new implementation.

Running the revised regression against the previous code is useful, but I would also include an adjacent boundary case that should keep its old behavior. A test can fail on the old code and still bless a new overcorrection. The pair checks both the intended fix and the behavior the ticket never asked to change.