fix: task timer shows wrong elapsed time in sidebar#1332
fix: task timer shows wrong elapsed time in sidebar#1332arnestrickmann merged 2 commits intogeneralaction:mainfrom
Conversation
|
@sairus2k is attempting to deploy a commit to the General Action Team on Vercel. A member of the Team first needs to authorize it. |
Greptile SummaryThis PR fixes the task timer in the sidebar showing wrong elapsed time (e.g. hours instead of "now") by extracting a
Confidence Score: 3/5
|
| Filename | Overview |
|---|---|
| src/renderer/lib/utils.ts | Introduces normalizeSqliteTimestamp() utility — the regex lacks a $ end anchor, meaning it can match and mangle timestamps that already carry a trailing timezone offset (e.g. git commit dates), producing an invalid ISO string. |
| src/renderer/components/TaskItem.tsx | Applies normalizeSqliteTimestamp() to formatCompactDate() — correct fix for task.updatedAt which is a SQLite UTC timestamp; no regressions introduced here. |
| src/renderer/components/diff-viewer/CommitList.tsx | Applies normalizeSqliteTimestamp() to formatRelativeDate() — git commit dates may already include timezone offsets and are not guaranteed to be in SQLite format; if they do, the unanchored regex can produce invalid date strings causing fallback to raw text display. |
| src/renderer/components/ui/relative-time.tsx | Refactors inline SQLite normalization logic in parseTimestamp() to use the new utility; behavior is functionally equivalent to the old code and the date-only + fallback paths are preserved correctly. |
| src/renderer/lib/prCommentsStatus.ts | Applies normalizeSqliteTimestamp() to formatRelativeTime() — timestamps here come from the GitHub API and are already ISO 8601, so the normalization is a safe no-op; the buildPrCommentsStatus sort still uses raw timestamps but that's consistent since GitHub timestamps don't need normalization. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Raw date string input] --> B{Matches SQLite pattern?}
B -- Yes --> C[Replace space with T and append Z]
B -- No --> D[Return unchanged]
C --> E[new Date normalized]
D --> E
E --> F{isNaN?}
F -- No --> G[Use parsed UTC Date for display]
F -- Yes --> H[NaN fallback or raw string]
subgraph Callers
T1[TaskItem.tsx]
T2[CommitList.tsx]
T3[relative-time.tsx]
T4[prCommentsStatus.ts]
end
T1 & T2 & T3 & T4 --> A
Last reviewed commit: 8c73e58
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| if (/^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/.test(dateStr)) { | ||
| return dateStr.replace(' ', 'T') + 'Z'; |
There was a problem hiding this comment.
Regex missing end anchor — may mangle timestamps with trailing timezone offsets
The regex /^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/ has no $ anchor after the seconds. This means any string that starts with the SQLite datetime pattern will match — including git commit dates that include a trailing timezone offset like "2024-01-01 12:00:00 +0000".
For such a string:
- The regex matches (starts with the pattern) ✓
.replace(' ', 'T')replaces only the first space →"2024-01-01T12:00:00 +0000"+ 'Z'appends →"2024-01-01T12:00:00 +0000Z"← invalid ISO 8601
new Date() will produce Invalid Date for that result. In CommitList.tsx this is caught by the isNaN guard and falls back to displaying the raw string, but in TaskItem.tsx and prCommentsStatus.ts there is no guard — new Date(...).getTime() would be NaN and the UI would show an empty string.
Anchoring the regex at the end (and only after the seconds, before any optional fractional-seconds or offset) prevents this misfiring:
| if (/^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}/.test(dateStr)) { | |
| return dateStr.replace(' ', 'T') + 'Z'; | |
| if (/^\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}(?:\.\d+)?$/.test(dateStr)) { | |
| return dateStr.replace(' ', 'T') + 'Z'; |
This accepts optional fractional seconds but rejects strings that continue with a space+timezone offset, leaving those untouched so existing JS Date parsing handles them correctly.
There was a problem hiding this comment.
Use the same regex as it was
|
|
||
| function formatRelativeDate(dateStr: string): string { | ||
| const date = new Date(dateStr); | ||
| const date = new Date(normalizeSqliteTimestamp(dateStr)); |
There was a problem hiding this comment.
normalizeSqliteTimestamp may not be appropriate for git commit dates
Git commit dates are not SQLite timestamps — they typically carry an explicit timezone offset, e.g. "2024-01-01 12:00:00 +0000" (from %ci) or a strict ISO-8601 string from %aI. As flagged in the utils.ts comment, the normalizeSqliteTimestamp helper is designed exclusively for SQLite's CURRENT_TIMESTAMP output (YYYY-MM-DD HH:MM:SS, no timezone).
If gitGetLog returns dates in a format with a trailing offset (e.g. "2024-01-01 12:00:00 +0000"), the current regex (without a $ anchor) will match and produce "2024-01-01T12:00:00 +0000Z" — an invalid date string — causing the isNaN guard to fall back to displaying the raw timestamp text.
It is worth verifying what exact format window.electronAPI.gitGetLog returns for commit.date. If it already emits proper ISO-8601 (e.g. "2024-01-01T12:00:00.000Z"), the normalization is a no-op and harmless; if it emits a space-separated datetime without a timezone offset, the fix is necessary. Adding a short comment noting the expected format would make the intent clear and prevent future confusion.
There was a problem hiding this comment.
Reverted for both commits and comments
|
Great improvement! |
2 participants
Summary
Task timer in sidebar shows wrong elapsed time — a newly created task immediately displays hours instead of "now".
normalizeSqliteTimestamp()utility to fix SQLite UTC timestamps being parsed as local timeFixes
If this PR fixes an issue, mention it like: Fixes #1331
Snapshot
Add screenshots, GIFs, or videos demonstrating the changes (if applicable)
Type of change
Mandatory Tasks
Checklist
pnpm run format)pnpm run lint)Test
Before the fix
After the fix