Skip to content

fix(tracking): parse RFC3339 timestamps in first_seen_days()#2711

Open
guyoron1 wants to merge 1 commit into
rtk-ai:developfrom
guyoron1:fix/tracking-first-seen-days-parse
Open

fix(tracking): parse RFC3339 timestamps in first_seen_days()#2711
guyoron1 wants to merge 1 commit into
rtk-ai:developfrom
guyoron1:fix/tracking-first-seen-days-parse

Conversation

@guyoron1

Copy link
Copy Markdown
Contributor

Summary

  • Fix first_seen_days() which always returns 0 due to timestamp parse format mismatch
  • Timestamps are stored as RFC3339 (2026-06-28T12:00:00.123456+00:00) but parsed with NaiveDateTime format %Y-%m-%dT%H:%M:%S — missing fractional seconds and timezone offset
  • Both parse attempts fail silently, falling back to Utc::now(), making (now - now).num_days() always 0
  • Use DateTime::parse_from_rfc3339() as primary parser (matching the existing correct usage on line 951 in the same file)
  • Keep NaiveDateTime formats as fallbacks for databases created by older RTK versions

Test plan

  • Added test_first_seen_days_parses_rfc3339 test verifying the function returns non-negative days
  • cargo clippy --all-targets passes
  • cargo test --all passes

Fixes #2710

Timestamps are stored via Utc::now().to_rfc3339() but first_seen_days()
parsed with NaiveDateTime format "%Y-%m-%dT%H:%M:%S" which rejects the
fractional seconds and timezone offset, silently falling back to
Utc::now() and always returning 0 days.

Use DateTime::parse_from_rfc3339() as primary parser (matching line 951
in the same file), keeping NaiveDateTime formats as fallbacks for older
databases.

Fixes rtk-ai#2710
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.

Bug: first_seen_days() always returns 0 — timestamp parse format mismatch

1 participant