OCTO-11628

[OlteanuRares]

WebVTTReader(time_shift_milliseconds=...) applied the shift with no lower bound. A cue shifted before 0 got a negative time, and Caption._format_timestamp() wrapped it to the end of a 24-hour clock:

• A cue crossing 0 became 23:59:59.500 --> 00:00:00.500, which is invalid WebVTT because the end is before the start.
• A cue entirely before 0 became 23:59:59.000 --> 23:59:59.800, a stray cue at the end of the timeline.

WebVTT, SRT and DFXP output wrapped the time; SAMI wrote start="-500".

Change
In WebVTTReader._parse_timing_line, when the shift is negative:

• Crosses 0: the start is clamped to 00:00:00.000 and the end is kept.
• Ends at or before 0: the cue is dropped. It is not wrapped and not kept as a zero-length cue. This also works for the last cue when the file has no trailing blank line.
• Every cue dropped: CaptionReadNoCaptions is raised, as for any empty file.
• Strict mode (ignore_timing_errors=False): inverted timings are still rejected, including on dropped cues. Clamped cues no longer fail the start-ordering check; on main, any cue shifted below 0 raised.
• Zero and positive shifts: unchanged.

[github-actions]

🟢 PR Compliance Review

Risk Level: LOW

• Compliance Issues: 0 (0 critical)
• Regressions: 0

SAFE TO MERGE - No critical issues found

Full report available in workflow artifacts