Skip to content

[BUG] Timestamp ranges are parsed as observation categories #1270

Description

@j2h4u

Bug Description

Timestamp range prefixes in transcript-style text are parsed as observation categories instead of being ignored as timestamps. This is a follow-up to #1219 and merged PR #1239: the single-clock matcher handles pure timestamps, but ranges containing two clocks are still misclassified.

Steps To Reproduce

  1. Use a note containing:

    [24:33.098 - 24:41.260] Speaker: We chose the safer option.
    
  2. Parse or index the note.

  3. Inspect the resulting observations.

Expected Behavior

The timestamp range should remain ordinary transcript content and should not become an observation category, matching the behavior for single timestamps fixed by #1239.

Actual Behavior

The range is accepted as an observation category:

24:33.098 - 24:41.260

Environment

  • Basic Memory: main at 346a519e21bb7d1ff0003146931ee72a49532628
  • Python: 3.14.6
  • Installation method: source checkout with uv
  • Claude Desktop version (if applicable): not applicable

Additional Context

PR #1239 deliberately added a narrow matcher for single clock values in MM:SS and HH:MM:SS forms, including fractional seconds. A range contains two valid clock values separated by - and therefore falls outside that matcher.

The reproduction above is synthetic and does not depend on a particular transcript or project.

Possible Solution

Extend the narrow timestamp exclusion to recognize spaced ranges containing two valid timestamp values, while preserving legitimate semantic categories such as [2024], [10:30am], and [v1:2]. Add focused regressions for fractional and non-fractional ranges.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions