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

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] 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.