Skip to content

Fix time-frame seeking: T/t were identical and never accumulated (and refactor RelativeDateTime) - #297

Merged
azat merged 2 commits into
mainfrom
fix-time-frame-seek
Aug 24, 2026
Merged

Fix time-frame seeking: T/t were identical and never accumulated (and refactor RelativeDateTime)#297
azat merged 2 commits into
mainfrom
fix-time-frame-seek

Conversation

@azat

@azat azat commented Aug 24, 2026

Copy link
Copy Markdown
Owner

Fixes: #296

azat and others added 2 commits August 24, 2026 16:03
Both AddAssign and SubAssign stored the raw rhs into the offset, so
"seek forward" behaved exactly like "seek backward" and repeated
presses replaced the offset instead of compounding it. Backward now
grows the always-subtracted offset, forward is its exact inverse, and
absolute datetimes shift date_time directly so (date_time, offset)
never combine and to_editable_string() keeps round-tripping.

Fixes: #296

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The struct allowed date_time and offset to be set simultaneously, a
state nothing creates since the seek fix but that to_sql_datetime_64()
still had to handle and to_editable_string() silently mishandled
(dropped the offset). The enum makes that state unrepresentable and
removes the dead arms; RelativeDateTime::new(None/Some) callers spell
the variant directly.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@azat
azat merged commit e7226e2 into main Aug 24, 2026
9 checks passed
@azat
azat deleted the fix-time-frame-seek branch August 24, 2026 14:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

RelativeDateTime AddAssign/SubAssign are identical: "Seek 10 mins forward" behaves like backward and repeated seeks don't accumulate

1 participant