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

[guyoron1]

Description

Tracker::first_seen_days() in src/core/tracking.rs always returns 0 because the timestamp parsing format doesn't match the storage format.

Root Cause

Timestamps are stored via Utc::now().to_rfc3339() (line 423), producing strings like:

2026-06-28T12:00:00.123456+00:00

But first_seen_days() (line 1108) tries to parse with:

NaiveDateTime::parse_from_str(&ts, "%Y-%m-%dT%H:%M:%S")

This fails because:

1. Fractional seconds (.123456) aren't in the format string
2. Timezone offset (+00:00) isn't in the format string
3. NaiveDateTime::parse_from_str requires the entire input to match

The second fallback format (%Y-%m-%d %H:%M:%S) also fails (wrong separator).

Both parse attempts fail, triggering unwrap_or_else(|_| chrono::Utc::now()) — so first is always "now", and (now - now).num_days() is always 0.

Comparison

Line 951 in the same file correctly parses timestamps:

DateTime::parse_from_rfc3339(&row.get::<_, String>(0)?)
    .map(|dt| dt.with_timezone(&Utc))

Impact

• Telemetry reports installation age as 0 days regardless of actual usage history
• Any feature relying on first_seen_days() gets incorrect data

Fix

Use DateTime::parse_from_rfc3339() as the primary parser, keeping the existing NaiveDateTime formats as fallbacks for databases created by older RTK versions.

[pszymkowiak]

wshm · Automated triage by AI

🔍 Automated Triage

🐛 Category	bug
🟡 Priority	medium
🎯 Confidence	97%

Summary

Timestamp parse format mismatch in first_seen_days() causes it to always return 0; fix is clear and a PR #2711 is already in progress.

This looks like a simple fix that could be auto-resolved. Repo maintainers can use /wshm fix to attempt it.

📁 Relevant files

• src/core/tracking.rs

---

Triaged automatically by wshm · This is an automated analysis, not a human review.