Fix colon-format timecode regexes rejecting >2-digit hours#45
Merged
Conversation
The hours capture group in all colon-separated timecode patterns was
`(\d\d{1})` (exactly two digits), so non-strict timecodes exceeding 99
hours (e.g. `100:00:00:00`) failed to match at the regex layer and raised
DFTTTimecodeTypeError before any strict/non-strict handling ran.
Change the hours group to `(\d{2,})` (2-or-more digits, unbounded) in
SMPTE_NDF/DF/union, SRT, FFMPEG, and DLP patterns. Keeping the `{2,}`
lower bound preserves the zero-pad requirement, so unpadded single-digit
hours (`1:00:00:00`) are still rejected. The output side already handled
large hours (`{:02d}` is a minimum width), so no core changes were needed.
Add tests covering >2- and 4-digit hours across all colon formats plus a
regression guard for single-digit rejection.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Commit c0b77be lifted the exactly-2-digit (max 99h) limit on the hours field of colon-separated timecodes, so the documented "-99 to 99 hours" range is no longer accurate. - index.rst: reword the "Extended Time Range" feature bullet to describe unbounded, zero-padded hours (e.g. 100:00:00:00) - zh_CN index.po/.mo: update the msgid to mirror the new source and retranslate the msgstr - CHANGELOG: add a bilingual [Unreleased] Fixed entry for the regex fix Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The .mo files are binary artifacts compiled from the .po sources. Sphinx auto-compiles .po -> .mo at build time (gettext_auto_build defaults to True), and CI's `make html-all` builds the translated site that way, so the committed .mo files are redundant and only add binary churn to diffs. Remove them from version control (files remain on disk) and ignore locale/**/*.mo. The .po files remain the tracked source of truth. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
OwenYou
reviewed
Jul 6, 2026
The lifted 99-hour cap on colon-separated timecodes reads as a new capability rather than a defect fix, so move the [Unreleased] entry from Fixed to Added and reword it in feature terms (both en and zh). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
OwenYou
self-requested a review
July 8, 2026 04:49
OwenYou
approved these changes
Jul 8, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The hours capture group in all colon-separated timecode patterns was
(\d\d{1})(exactly two digits), so non-strict timecodes exceeding 99 hours (e.g.100:00:00:00) failed to match at the regex layer and raised DFTTTimecodeTypeError before any strict/non-strict handling ran.Change the hours group to
(\d{2,})(2-or-more digits, unbounded) in SMPTE_NDF/DF/union, SRT, FFMPEG, and DLP patterns. Keeping the{2,}lower bound preserves the zero-pad requirement, so unpadded single-digit hours (1:00:00:00) are still rejected. The output side already handled large hours ({:02d}is a minimum width), so no core changes were needed.Add tests covering >2- and 4-digit hours across all colon formats plus a regression guard for single-digit rejection.