[BUG] Routines inject UTC date instead of user's local timezone

[iaiiei]

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:

• [FEATURE] add optional timezone field (IANA tz, e.g. America/Los_Angeles) to scheduled-trigger cron expressions #50529 — [FEATURE] add optional timezone field (IANA tz) to scheduled-trigger cron expressions. Adjacent but distinct: [FEATURE] add optional timezone field (IANA tz, e.g. America/Los_Angeles) to scheduled-trigger cron expressions #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.
• Feature Request: Expose message timestamps to the model and display them in the UI #49692 — earlier combined issue of mine, closed as dup of Expose message timestamps to the model in Claude Code sessions #47160; this Routines-specific timezone bug was not carried over.
• Expose message timestamps to the model in Claude Code sessions #47160 — related root-cause area (timestamp handling), but a distinct technical problem.

[LaRochelleRochelle]

Confirming this also affects regular interactive Claude Code sessions, not just Routines.

In a standard chat session (AEST, UTC+10), the injected currentDate showed 2026-04-23 with no day name or timezone - Claude inferred the wrong day name (Wednesday instead of Thursday). The UTC offset issue is not limited to scheduled Routines; it appears to be systemic across all session types where currentDate is injected.

[varunDMG]

The Routines calendar view itself is wrong. The weekday calculation for "weekdays" is also UTC-based, shifting the schedule to Tue-Sat instead of Mon-Fri.

[svobom57]

2nd this. I have a "Morning briefing" routine that should run in GMT +7:

But Claude always generates the routine for yesterday. So today's 1 May 8:00 AM run resulted in:

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[nweii]

Still happening for me. I'm in New York time and run routines in the evening — when one fires at 8pm, the injected "Today's date" already says tomorrow, because by then it's past midnight in UTC. So a routine I've told to work on "yesterday's" note works on today's instead.

For now I've worked around it by not trusting the injected date in my prompts and having the routine run TZ=America/New_York date itself. Would be good to see this reopened.