Today period uses UTC date instead of local timezone — wrong 'today' for non-UTC users

[eugene-eee-hongkyu]

Description

codeburn report --period today returns the date label and daily entry using UTC, ignoring the user's local timezone. For users in non-UTC zones (SGT/KST/etc), this produces a wrong "today" date for several hours each day.

Steps to Reproduce

On a SGT (UTC+8) machine at local time 07:08 (= UTC 23:08 the day before):

$ date
Fri May  1 07:08:14 +08 2026

$ date -u
Thu Apr 30 23:08:15 UTC 2026

$ codeburn report --period today --format json --provider claude

Output:

{
  "period": "Today (2026-04-30)",
  "periodKey": "today",
  "daily": [
    { "date": "2026-04-30", "cost": 50.13, "calls": 180 }
  ]
}

Expected

For a user whose local time is May 1, codeburn today should return 2026-05-01 (and aggregate sessions logged on the user's local May 1).

Actual

codeburn returns 2026-04-30 because it is still April 30 in UTC at that moment. Sessions logged between local midnight and UTC midnight (8 hours in SGT, 9 hours in KST) are bucketed into the previous calendar day, and the user sees yesterday's data labeled as "today".

Impact

• Users in non-UTC timezones see incorrect "today" data during early-morning hours
• Daily breakdowns split a single local calendar day across two UTC dates
• Downstream tooling that chains codeburn output needs to work around this (e.g., we ended up using ccusage's daily output, which already respects local time, as the canonical date source)

Cross-reference

ccusage daily --json (https://www.npmjs.com/package/ccusage), run on the same machine at the same moment, correctly returns date: "2026-05-01" entries. So Date.now() parsing in local time clearly works in npm CLI environments — codeburn appears to compute dates from Date.toISOString() or similar UTC-based formatters.

Suggestion

• Use the local system timezone by default for date computation (matches user expectation and other ecosystem tools like ccusage)
• Optional --timezone <iana-zone> flag for explicit override
• If UTC behavior must remain default for backward compatibility, document it prominently in --help output

Thanks for the great tool!

[iamtoruk]

Fixed in #186. Three changes:

Menubar (Swift): computeHistoryStats in FindingsSection.swift hardcoded TimeZone(identifier: "UTC") and effectiveTokensInLast7Days in AppStore.swift used ISO8601DateFormatter() (defaults to UTC). Both now use .current timezone. This was the primary cause of wrong dates in the menubar for non-UTC users.

CLI: The CLI's date functions (dateKey, toDateString, getDateRange) already use local-timezone getters, so codeburn report --period today --format json produces correct local dates under normal conditions. However, environments where Node.js doesn't inherit the system timezone (Docker, cron, LaunchAgents) would see UTC dates. New --timezone flag and CODEBURN_TZ env var let you override explicitly:

codeburn report --period today --timezone Asia/Singapore
# or
export CODEBURN_TZ=Asia/Seoul
codeburn report --period today

DST fix: Replaced todayStart - 86400000ms with new Date(y, m, d-1) for yesterday/backfill date arithmetic. The millisecond subtraction skips a day on DST spring-forward (23-hour day).