Skip to content

fix(commands): read grep --since/--until as local calendar days - #334

Merged
AnnatarHe merged 1 commit into
mainfrom
fix/grep-local-dates
Oct 23, 2026
Merged

AnnatarHe merged 1 commit into
mainfrom
fix/grep-local-dates

Conversation

@AnnatarHe

@AnnatarHe AnnatarHe commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Summary

I audited every CLI → server payload for timezone handling. They all already send absolute instants, so the data lands in UTC wherever the CLI is installed:

Payload Field and format
track startTime/endTime (+ nano), Unix
heartbeats time, Unix seconds
OTEL events and metrics timestamp/timestampMs, from TimeUnixNano
OTEL spans *UnixNano
backfill events Unix seconds, parsed from the agents' RFC 3339 Z timestamps
backfill complete from/to, RFC 3339 with offset (same instant)
codex-usage resets_at, .UTC() RFC 3339
anthropic-usage resets_at, Anthropic's own RFC 3339
statusline / cc info queries send local midnight converted to UTC

The one CLI-side mismatch: shelltime grep --since/--until turned the dates into UTC days. --since 2026-10-23 in Tokyo started at 09:00 local time. They are now calendar days of the machine's timezone, matching aicode backfill --since/--until and the statusline's "today". The server still only receives Unix seconds. The flag help says "in local time".

Related server work, which makes the server bucket days and hours in the client's zone: shelltime/server#561. Web side: shelltime/web#725.

Test plan

  • go test ./commands/ -run 'Grep|ParseFlexibleDate|Filter' passes with TZ unset, America/Los_Angeles and Asia/Kolkata.
  • New TestParseFlexibleDate_UsesMachineTimezone pins JST midnight and end of month.
  • The full ./commands run fails in TestTrackTestSuite both on main and on this branch: this cloud session has a real daemon on /tmp/shelltime.sock. That failure is unrelated to this change.

Generated by Claude Code


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need.

The server receives the filter as Unix seconds, but the dates were parsed
as UTC days, so `shelltime grep --since 2026-10-23` in Tokyo started at
09:00 local time. Parse them in the machine's timezone, like backfill's
--since/--until and the statusline's "today".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GuwzysFHhG6n8joc6ja7gW
@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ⚠️ Failed 2026-10-23T05:24:10.305071Z
We couldn’t complete this review. Comment @codex review to try again.
760308d PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@github-actions

Copy link
Copy Markdown
Contributor

⏱️ shelltime track performance

✅ No significant change in shelltime track latency

Comparing main @ babae9d → #334 @ 760308d. Each scenario execs the binary the way the shell hooks do; values are the median of 10 interleaved rounds. Lower is better.

Scenario base head Δ p
Startup/floor 176 µs ±20% 173 µs ±8% ~ 0.684 A/A
Startup/version 2.19 ms ±11% 2.03 ms ±9% -7.31% 0.023 ✅
Track/daemon/pre 2.15 ms ±10% 2.28 ms ±9% ~ 0.529 ✅
Track/daemon/post 2.30 ms ±9% 2.28 ms ±10% ~ 0.684 ✅
Track/direct/pre 2.29 ms ±10% 2.26 ms ±7% ~ 0.579 ✅
Track/direct/post 4.42 ms ±7% 4.58 ms ±8% ~ 0.353 ✅
Track/direct/post-sync 5.59 ms ±5% 5.47 ms ±12% ~ 0.739 ✅

Binary size: 19.2 MiB → 19.2 MiB (+0.0%).

CPU, tail latency and memory

Per exec, base → head (Δ when significant).

Scenario p95 wall user CPU sys CPU peak RSS
Startup/floor 226 µs → 224 µs 152 µs → 147 µs 5 µs → 5 µs 9.2 MiB → 9.2 MiB
Startup/version 2.74 ms → 2.70 ms 1.60 ms → 1.53 ms 613 µs → 540 µs 15.5 MiB → 15.5 MiB
Track/daemon/pre 2.76 ms → 2.81 ms 1.56 ms → 1.65 ms 649 µs → 663 µs 16.5 MiB → 16.5 MiB
Track/daemon/post 2.87 ms → 2.81 ms 1.62 ms → 1.65 ms 645 µs → 627 µs 16.4 MiB → 16.4 MiB
Track/direct/pre 2.87 ms → 2.91 ms 1.67 ms → 1.59 ms 674 µs → 711 µs 16.4 MiB → 16.4 MiB
Track/direct/post 5.70 ms → 6.12 ms 3.10 ms → 3.07 ms 1.59 ms → 1.54 ms 17.6 MiB → 17.6 MiB
Track/direct/post-sync 6.83 ms → 6.94 ms 4.20 ms → 4.09 ms 1.81 ms → 1.91 ms 19.5 MiB → 19.5 MiB
benchstat
goos: linux
goarch: amd64
pkg: github.com/malamtime/cli/perf
cpu: AMD EPYC
                         │     base     │                head                 │
                         │    sec/op    │    sec/op     vs base               │
Startup/floor-2            176.4µ ± 20%   173.4µ ±  8%       ~ (p=0.684 n=10)
Startup/version-2          2.190m ± 11%   2.030m ±  9%  -7.31% (p=0.023 n=10)
Track/daemon/pre-2         2.151m ± 10%   2.282m ±  9%       ~ (p=0.529 n=10)
Track/daemon/post-2        2.301m ±  9%   2.283m ± 10%       ~ (p=0.684 n=10)
Track/direct/pre-2         2.292m ± 10%   2.265m ±  7%       ~ (p=0.579 n=10)
Track/direct/post-2        4.424m ±  7%   4.579m ±  8%       ~ (p=0.353 n=10)
Track/direct/post-sync-2   5.587m ±  5%   5.467m ± 12%       ~ (p=0.739 n=10)
geomean                    1.953m         1.941m        -0.58%

                         │     base     │                head                 │
                         │  p50-sec/op  │  p50-sec/op   vs base               │
Startup/floor-2            165.7µ ± 10%   161.2µ ±  8%       ~ (p=0.529 n=10)
Startup/version-2          2.113m ± 13%   1.892m ± 11%       ~ (p=0.063 n=10)
Track/daemon/pre-2         2.033m ± 17%   2.130m ± 11%       ~ (p=0.739 n=10)
Track/daemon/post-2        2.165m ± 12%   2.223m ± 10%       ~ (p=0.579 n=10)
Track/direct/pre-2         2.208m ± 11%   2.163m ±  9%       ~ (p=0.529 n=10)
Track/direct/post-2        4.253m ±  4%   4.314m ±  7%       ~ (p=0.739 n=10)
Track/direct/post-sync-2   5.467m ±  6%   5.357m ±  9%       ~ (p=0.853 n=10)
geomean                    1.867m         1.843m        -1.30%

                         │     base     │                head                 │
                         │  p95-sec/op  │  p95-sec/op   vs base               │
Startup/floor-2            226.3µ ± 19%   223.8µ ± 21%       ~ (p=0.739 n=10)
Startup/version-2          2.740m ± 21%   2.699m ± 14%       ~ (p=0.190 n=10)
Track/daemon/pre-2         2.756m ± 13%   2.809m ± 11%       ~ (p=0.684 n=10)
Track/daemon/post-2        2.867m ± 10%   2.809m ± 12%       ~ (p=0.853 n=10)
Track/direct/pre-2         2.866m ± 16%   2.909m ±  9%       ~ (p=0.971 n=10)
Track/direct/post-2        5.698m ±  9%   6.116m ± 12%       ~ (p=0.353 n=10)
Track/direct/post-sync-2   6.835m ± 14%   6.942m ± 18%       ~ (p=0.912 n=10)
geomean                    2.461m         2.487m        +1.06%

                         │     base     │                head                 │
                         │  peak-rss-B  │  peak-rss-B   vs base               │
Startup/floor-2            9.150Mi ± 2%   9.178Mi ± 1%       ~ (p=0.811 n=10)
Startup/version-2          15.52Mi ± 0%   15.51Mi ± 0%       ~ (p=0.490 n=10)
Track/daemon/pre-2         16.51Mi ± 0%   16.52Mi ± 0%       ~ (p=0.205 n=10)
Track/daemon/post-2        16.40Mi ± 0%   16.40Mi ± 0%       ~ (p=0.781 n=10)
Track/direct/pre-2         16.38Mi ± 0%   16.38Mi ± 0%       ~ (p=0.538 n=10)
Track/direct/post-2        17.57Mi ± 0%   17.57Mi ± 0%       ~ (p=0.541 n=10)
Track/direct/post-sync-2   19.52Mi ± 0%   19.49Mi ± 0%       ~ (p=0.435 n=10)
geomean                    15.51Mi        15.51Mi       +0.03%

                         │     base     │                head                 │
                         │  sys-sec/op  │  sys-sec/op   vs base               │
Startup/floor-2            5.350µ ± 49%   5.415µ ± 37%       ~ (p=0.739 n=10)
Startup/version-2          612.6µ ± 19%   540.5µ ± 28%       ~ (p=0.165 n=10)
Track/daemon/pre-2         649.0µ ± 16%   662.9µ ± 29%       ~ (p=0.739 n=10)
Track/daemon/post-2        644.7µ ± 22%   627.1µ ± 31%       ~ (p=0.912 n=10)
Track/direct/pre-2         673.6µ ± 34%   711.4µ ± 38%       ~ (p=0.739 n=10)
Track/direct/post-2        1.585m ± 20%   1.544m ± 16%       ~ (p=0.853 n=10)
Track/direct/post-sync-2   1.812m ± 18%   1.908m ± 18%       ~ (p=0.481 n=10)
geomean                    428.5µ         426.1µ        -0.56%

                         │     base     │                head                 │
                         │ user-sec/op  │ user-sec/op   vs base               │
Startup/floor-2            151.6µ ± 14%   147.3µ ± 10%       ~ (p=0.529 n=10)
Startup/version-2          1.600m ±  9%   1.534m ±  4%       ~ (p=0.075 n=10)
Track/daemon/pre-2         1.562m ±  8%   1.648m ± 10%       ~ (p=0.315 n=10)
Track/daemon/post-2        1.616m ±  9%   1.651m ±  6%       ~ (p=0.436 n=10)
Track/direct/pre-2         1.671m ±  2%   1.592m ±  7%       ~ (p=0.123 n=10)
Track/direct/post-2        3.102m ±  5%   3.068m ± 14%       ~ (p=0.853 n=10)
Track/direct/post-sync-2   4.201m ±  7%   4.090m ± 14%       ~ (p=0.481 n=10)
geomean                    1.448m         1.431m        -1.16%

Δ compares medians; ~ means no significant difference (Mann-Whitney U, p ≥ 0.05). A scenario is flagged when it is more than 10% and more than 250µs slower with p < 0.05. Startup/floor runs true, not shelltime: it is an A/A check of runner noise. Runner: linux/amd64, AMD EPYC. go1.27.1, 10 rounds × 100 execs per scenario and binary.

@codecov

codecov Bot commented Oct 23, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag Coverage Δ
unittests 86.36% <100.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines Coverage Δ
commands/grep.go 97.91% <100.00%> (ø)

... and 2 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@shelltime

shelltime Bot commented Oct 23, 2026 •

Copy link
Copy Markdown

☁️ Claude Code cloud · Normalize CLI data to UTC and fix viewer timezone handling

Audited CLI-originated timestamps and updated server/web timezone handling so stored data remains UTC while reports and views use the viewer’s local timezone.

💰 Cost 🔢 Tokens ⏱️ Duration 🧠 Models 💬 Prompts ✏️ Lines
$33.73 114.3M 56m (40m active) claude-opus-5-5, claude-haiku-5-5 1 +415 / −0

114.3M tokens: 2.5K input · 238.5K output · 113.1M cache read · 956.3K cache write

📝 AI summary

Reviewed the CLI-to-server data path and timezone-sensitive reporting behavior to enforce the rule that CLI data is normalized to UTC regardless of where the CLI is installed. Updated /home/user/server/schema/activity.timezone.go to correct timezone-aware activity bucketing, and added coverage in /home/user/server/schema/timezone_buckets_test.go and /home/user/server/tasks/report_local_hour_test.go for local-hour reports and timezone bucket behavior.

Updated /home/user/web/src/service/viewer-timezone.server.ts so the web application supplies the viewer’s timezone when requesting or presenting data, allowing UTC-backed records to be interpreted correctly for each user. The session used repository searches, targeted file inspection, edits, shell commands, and delegated analysis to audit related paths; no iOS files required changes in this pass.

View this session on ShellTime →

Updated 2026-10-24 05:25 UTC by ShellTime · totals for the whole session so far · the session page is visible to its owner

@AnnatarHe
AnnatarHe merged commit c75ec6a into main Oct 23, 2026
5 checks passed
@AnnatarHe
AnnatarHe deleted the fix/grep-local-dates branch October 23, 2026 10:11
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.

2 participants