Time anchor

Time Anchor (Single-File Edition)

About this file: This skill ships in two forms: a multi-file version (cleaner UX, requires platform sync support) and this single-file version (works in every Claude environment today). You're reading the single-file version. The protocol instructions and your time preferences live in the same document — Claude reads both at session start.

To use this skill:

1. Replace the values in the "USER TIME RULES" section at the bottom with your actual timezone and preferences
2. Save the file
3. The protocol instructions above the line tell Claude how to handle the rules below the line

Don't edit anything above the ===== USER TIME RULES BELOW ===== marker unless you want to change Claude's behavior. Edit only the content below it.

---

Protocol — How Claude handles time

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 (in the USER TIME RULES section below).

When to load

Load this skill:

• At the start of every conversation where the user works on long-term projects
• 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 the USER TIME RULES section below. 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 the rules say 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...")

How to handle conflicts between user statements and the clock

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 the rules below if they've drifted from reality (DST change, travel, etc.).

---

===== USER TIME RULES BELOW =====

Time Rules

How to use this section: Fill in your timezone and any preferences. Update if you travel or your situation changes. Claude reads this whenever the time-anchor skill loads.

---

Timezone (required)

IANA timezone: America/Boise

Use IANA format (the standard timezone names). Examples:

• America/New_York (Eastern)
• America/Chicago (Central)
• America/Denver (Mountain — most of the Mountain time zone)
• America/Boise (Mountain — Idaho specifically)
• America/Phoenix (Arizona, no DST)
• America/Los_Angeles (Pacific)
• Europe/London
• Europe/Berlin
• Asia/Tokyo
• Asia/Singapore
• Australia/Sydney

Find yours at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

---

Locale and date format preference

Locale: en-US Date format I prefer: Month Day, Year (e.g., "May 3, 2026")

Other common preferences:

• ISO format: 2026-05-03
• European format: 3 May 2026
• Numeric US: 5/3/2026
• Numeric EU: 3/5/2026

---

My typical day rhythm

Optional but useful. Tell Claude when you typically work, sleep, take meetings. This helps Claude calibrate phrases like "early," "late," "evening" to your actual life.

• I have variable hours — replace with yours
• Don't assume traditional 9-5 patterns

---

Travel exceptions

If you're traveling, list it here so Claude knows to use a different timezone temporarily. Update or remove as travel ends.

Currently: none

Format example for when you travel:

• 2026-06-15 to 2026-06-20: Boston (America/New_York)
• 2026-09-01 to 2026-09-08: Tokyo (Asia/Tokyo)

---

Quiet hours / do-not-disturb

Optional. Tell Claude when not to suggest "let's schedule a meeting" or to recognize that you're outside normal availability.

[your quiet hours, or "none"]

---

Time-related rules / preferences

Anything specific Claude should know about how you want time handled.

• When I say "tonight," I mean tonight in my timezone — even if the system clock is in UTC
• If you're not sure what timezone "tomorrow" or "this week" refers to, ask — don't guess
• Don't apologize for clarifying time. Getting it right matters more than seeming smooth.

[Add or remove rules to match your preferences]

---

Last updated: YYYY-MM-DD Update this date whenever you change anything in this file (DST, travel, schedule changes).