Nope, the programming's doing what it was specified to do. The problem here is twofold:

1. the operator didn't engage brain, and realise that setting the time to 0.05 without also changing the date would bring the flight forward 23h50m, rather than push it back 10m, and;
2. the people who drew up the specifications (likely to be the system's commissioning purchaser rather than the developers) didn't anticipate this scenario and put in a warning along the lines of: "This may not be what you intended: please confirm." From experience, clients tend to concentrate on the mission-critical issues in specifications, rather than catching gotchas, which is why this was probably not included. If the developers did pick up on that, chances are it would be rejected by the commissioner in order to cost-constrain the development.

Operators doing bulk reschedules should be trained to pick up day-straddle issues like this - it's part of their job. This was a training failure, and rectification should largely be a case of adjusting the nut behind the keyboard.

(And, yes, this is my professional domain, in case it wasn't obvious.)