← Back to PRs

#19611: fix: use local timezone in log file and console timestamps

by tag-assistant open 2026-02-18 01:10 View on GitHub →
size: XS
## Summary Log timestamps in the structured JSON log file and some console formats use `Date.toISOString()` which always outputs UTC (`Z` suffix). This is confusing when reading logs on a local machine — you have to mentally convert to your timezone. The console capture layer already uses `formatLocalIsoWithOffset()` from `src/logging/timestamps.ts` which produces local ISO-8601 timestamps with the correct offset (e.g. `2026-02-17T19:15:08.686-05:00`). This PR updates the remaining three call sites to use the same function: 1. **`logger.ts`** — file transport `time` field 2. **`subsystem.ts`** — JSON console style `time` field 3. **`subsystem.ts`** — pretty/compact console timestamp prefixes ## Changes - `src/logging/logger.ts`: Replace `toISOString()` with `formatLocalIsoWithOffset()` in the file transport - `src/logging/subsystem.ts`: Replace 3 `toISOString()` calls with `formatLocalIsoWithOffset()` ## Testing All 39 logging tests pass. No new tests needed — `formatLocalIsoWithOffset` already has dedicated test coverage in `timestamps.test.ts`. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR standardizes all logging timestamps to use local timezone with UTC offset instead of UTC (`Z` suffix). It replaces `Date.toISOString()` calls in `logger.ts` (file transport) and `subsystem.ts` (JSON console, pretty console, compact console) with the existing `formatLocalIsoWithOffset()` helper from `timestamps.ts`, which was already used by the console capture layer. - All 4 `toISOString()` call sites in the logging module are now replaced, producing timestamps like `2026-02-17T19:15:08.686-05:00` instead of `2026-02-17T00:15:08.686Z` - Downstream log consumers (`parseLogLine`, `formatLogTimestamp`) handle both formats correctly since `new Date()` parses ISO-8601 timestamps with offsets - No remaining `toISOString()` calls in `src/logging/` - The `.slice(11, 19)` extraction for pretty-mode timestamps remains correct since both formats share the same character positions for the time component <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — it's a minimal, well-scoped change that aligns remaining timestamp call sites with an already-established pattern. - The change is small (4 call sites across 2 files), uses an existing well-tested utility function, and all downstream consumers handle the new format correctly. No logic changes beyond the timestamp format, no new dependencies, and existing tests pass. - No files require special attention. <sub>Last reviewed commit: 38cd6d4</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs