Time anchor

Time Anchor Skill

Purpose

Claude regularly gets the current date and time wrong. Common failure modes:

• Saying "tonight" when it's morning in the user's timezone
• Assuming "this week" continues from a previous conversation when it's actually been weeks
• Defaulting to UTC or server-side timezones when the user is in a different one
• Carrying over time-of-day from earlier in a conversation even when the user has come back hours later
• Not noticing when a date in the prompt has changed since the conversation started

This skill fixes those failures by giving Claude an explicit instruction set for time handling, plus a place for the user to declare their timezone, locale, and preferences.

When to load

Load this skill:

• At the start of every conversation where the user works on long-term projects (default-load when paired with project-anchor)
• Any time the user uses time-relative language: today, tonight, tomorrow, this morning, this afternoon, this evening, yesterday, last night, last week, next week, next month, "in a bit," "later," "soon," "just now," etc.
• Any time the user asks a question whose answer depends on the current time: "is it too late to send X?", "what day is it?", "how long until Y?"

Core rules

Rule 1 — The system clock is the truth.

The conversation prompt contains the current date and (where available) time. Always read it. Never infer the current time from:

• What the user said earlier in the conversation
• What time you assumed it was at the start of the conversation
• A "default" assumption like "it's probably evening because the user is wrapping up"
• The pace, length, or tone of recent messages

If the prompt says "Sunday, May 03, 2026" then today is Sunday, May 03, 2026 — even if the conversation has been going for hours and feels like it might have rolled into a new day.

Rule 2 — Resolve time to the user's local timezone.

Read time_rules.md from this skill's folder. The user has declared their timezone, locale, and any travel exceptions. Convert system time (often UTC or server-local) to the user's actual local time before referencing time of day.

If time_rules.md says the user is in America/Boise (Mountain Time), and the system prompt timestamp is 14:00 UTC, the user's local time is 08:00 MT. Refer to it as morning, not afternoon.

Rule 3 — Match precision to the user's question.

• "What day is it?" — give the date.
• "Is it morning?" — give the rough time-of-day for their timezone.
• "What time is it exactly?" — give the time as precisely as the system clock provides.
• Don't volunteer time information when it isn't relevant. Don't tell the user it's Sunday morning when they asked you to fix a bug.

Rule 4 — Recognize ambiguous time references and resolve them.

• "This morning" → the morning of today, in the user's timezone, NOT the morning of when the conversation started
• "Tonight" → the evening/night of today, NOT some prior night that came up earlier in the conversation
• "Last week" → the calendar week prior to the current week, NOT "the last time we talked"
• "A few hours ago" → relative to the current system time, NOT relative to your last response

Rule 5 — When in doubt, surface the actual date.

If you're uncertain whether you're getting the time right, say the date and let the user correct you:

• ✅ "It's Sunday, May 3 here in your timezone — late morning. Want me to schedule that for tomorrow?"
• ❌ "I'll schedule that for tomorrow." (with no anchor — the user can't verify you understood "tomorrow" correctly)

Rule 6 — Time changes during a conversation.

A long conversation may span actual hours. The user may step away and come back. Re-check the system clock when:

• The user references "now" or current time after a gap
• More than 30 minutes have elapsed since your last clock reference
• The user mentions doing something that implies elapsed time ("ok I'm back")
• You're about to make a time-sensitive recommendation (deadlines, schedules, "is it too late to...")

What to read from time_rules.md

Read the file. It contains:

• The user's timezone (IANA format, e.g., America/Boise)
• The user's locale and date-format preference (e.g., US format, ISO format)
• Any travel notes (e.g., "I'm in Tokyo this week")
• Quiet hours or do-not-disturb windows the user has declared
• Any time-related preferences (e.g., "I work nights, don't assume morning equals start-of-workday")

Treat time_rules.md the same way you'd treat any other ground-truth file: trust it, surface conflicts honestly, never modify silently.

What this skill protects against

• Saying "tonight" when it's morning
• Saying "this morning" when 4 hours have passed since the conversation started
• Defaulting to server-side UTC times when the user is in a different timezone
• Mis-resolving "tomorrow" or "last week" relative to a conversational anchor instead of the actual clock
• Suggesting someone "go to bed" or commenting on time-of-day when the user has explicit rules against that

How to handle conflicts

If the user says something that contradicts the system clock — e.g., they say "good morning" but the system says it's 11pm in their timezone — the user is right about their experience, but the system clock is right about absolute time. Acknowledge both gently:

"Good morning! (For my own reference: the system has it as 11:47 PM your local time — let me know if you've adjusted your timezone or are traveling.)"

This lets the user correct time_rules.md if it's drifted from reality (DST change, travel, etc.).