claude-code - 💡(How to fix) Fix [BUG] Routines inject UTC date instead of user's local timezone

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Error Messages/Logs

Root Cause

The offset is consistently −1 day for JST users during the early-morning window, because UTC still shows the previous calendar day.

Fix Action

Fix / Workaround

Current workaround: Adding TZ=Asia/Tokyo date to the Routine prompt so Claude re-derives the correct date from the shell on every run. This works, but:

  • It shouldn't be necessary — the user's timezone is known to the platform.
  • It doesn't fix the injected # currentDate context; Claude has to actively ignore it.
  • Other users in non-UTC timezones will hit this same bug and need to discover the workaround independently.

Code Example

# Routine fired at 05:30 JST on 2026-04-16

# currentDate
Today's date is 2026-04-15.   ← wrong; this is the UTC calendar date at that moment
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report
  • I am using the latest version of Claude Code (web UI, claude.ai/code)

What's Wrong?

When a Claude Code Routine (scheduled task) fires, the system injects a # currentDate / "Today's date" value into the session context. For users in non-UTC timezones, this date is wrong — it uses UTC instead of the user's local timezone, producing a 1-day offset during the early-morning local window.

What Should Happen?

The injected date should reflect the user's local timezone (from account settings, or from the Routine's schedule timezone), not UTC.

Error Messages/Logs

# Routine fired at 05:30 JST on 2026-04-16

# currentDate
Today's date is 2026-04-15.   ← wrong; this is the UTC calendar date at that moment

Steps to Reproduce

  1. Set account timezone to Asia/Tokyo (JST, UTC+9).
  2. Create a Routine scheduled to run daily at 05:30 JST.
  3. Let it fire at 05:30 JST on any date, e.g. 2026-04-16.
  4. At 05:30 JST, UTC is still ~20:30 on April 15.
  5. Expected: injected date = 2026-04-16.
  6. Actual: injected date = 2026-04-15 (one day behind).

The offset is consistently −1 day for JST users during the early-morning window, because UTC still shows the previous calendar day.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

N/A

Claude Code Version

N/A — web UI (claude.ai/code), Max 20x plan

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Non-interactive/CI environment

Additional Information

Impact: For a user whose Routines run in the early morning local time, Claude starts every day with the wrong date. This cascades into wrong deadline calculations, wrong "X days remaining" counts, and confused conversation logs.

Current workaround: Adding TZ=Asia/Tokyo date to the Routine prompt so Claude re-derives the correct date from the shell on every run. This works, but:

  • It shouldn't be necessary — the user's timezone is known to the platform.
  • It doesn't fix the injected # currentDate context; Claude has to actively ignore it.
  • Other users in non-UTC timezones will hit this same bug and need to discover the workaround independently.

Related:

  • #50529[FEATURE] add optional timezone field (IANA tz) to scheduled-trigger cron expressions. Adjacent but distinct: #50529 is about making the schedule itself timezone-aware (DST drift on UTC cron). This bug is about the injected currentDate value seen by the session after it fires — the two fixes are independent.
  • #49692 — earlier combined issue of mine, closed as dup of #47160; this Routines-specific timezone bug was not carried over.
  • #47160 — related root-cause area (timestamp handling), but a distinct technical problem.

extent analysis

TL;DR

The issue can be fixed by adjusting the timezone used for injecting the # currentDate value in Claude Code Routines to match the user's local timezone.

Guidance

  • Verify that the user's timezone is correctly set in their account settings and that the Routine's schedule timezone is also set to the user's local timezone.
  • Consider modifying the code that injects the # currentDate value to use the user's local timezone instead of UTC.
  • Test the fix by running a Routine at a time when the UTC date would be different from the user's local date, such as early morning in a non-UTC timezone.
  • Review related issues, such as #50529 and #47160, to ensure that the fix does not introduce any new problems with timezone handling.

Example

No code snippet is provided as the issue does not include specific code details.

Notes

The fix may require changes to the Claude Code platform's handling of timezones, which could have implications for other features and users. It is essential to thoroughly test the fix to ensure it works correctly for all users and timezones.

Recommendation

Apply a workaround by modifying the Routine to use the user's local timezone for date calculations until a permanent fix is implemented. This will ensure that users in non-UTC timezones receive the correct date in their Routines.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Routines inject UTC date instead of user's local timezone