Project calendar

Your project calendar is the timezone your community lives in. It decides when "today", "this week" and "this month" start. For example:

• A daily check-in quest resets at midnight in Budapest, not in London.
• A weekly leaderboard runs Monday to Sunday in New York time.
• A "3 per month" limit starts fresh on the 1st, in your timezone.

Limits (budgets), streaks and calendar leaderboards all count periods of this one calendar, so a weekly limit and a weekly leaderboard always cover the same week. Each environment has its own. Until you choose a timezone, the calendar is UTC.

What follows the calendar

Budgets and leaderboards can count the same completion in different periods. A quest's points are awarded when its attempt is accepted, but its budget is charged in the period of the activity. A tracker activity from Monday that is accepted on Tuesday, after a deferral or review, spends Monday's daily budget and counts on Tuesday's daily leaderboard. Domino does not date a quest's points back to the activity, because that window may already be settled.

• Days start at local midnight. On daylight-saving days a day lasts 23 or 25 hours.
• Weeks start on Monday. They are ISO weeks.
• Months are calendar months.
• Nothing names its own timezone. A quest, budget, streak or board cannot override the project calendar. For a season on fixed dates, give a leaderboard fixed dates instead.
• Some things count plain time. A tracker's window runs from one moment to another, and a referral bonus's duration counts days since the friend qualified. Neither follows the calendar.

Use the calendar in an evaluator

Call ctx.calendar.day() to read the project-calendar day containing ctx.eligibleAt. It returns a stable key plus the local date, timezone, and epoch-millisecond bounds:

import { keyed } from "@domino-sdk/relay/authoring"

const daily = keyed(({ calendar }) => calendar.day().key)
// For example: 2026-10-01@Europe/Budapest

Pass an instant as ctx.calendar.day(at) to read another day. start is inclusive and end is exclusive. A day can last 23 or 25 hours around daylight saving, and the first day after a timezone change can be shorter. Use the returned bounds; do not calculate them by adding 24 hours. How the calendar is pinned for retries is in evaluation time and randomness.

Choose the timezone

In Console, open Settings → General → Project calendar, choose a timezone, give a reason, and save. Pick a city, such as Europe/Budapest or America/New_York, or UTC. Fixed offsets such as +02:00, Etc/GMT-2 and EST are refused, because they ignore daylight saving: half the year, their midnight would be an hour off.

Choose the timezone before launch. A change mid-campaign is safe, but the first period after it can be short; see When the timezone changes.

• The latest decision wins. A deployment changes the calendar only when relay.json declares a different timezone from the last deployment. A change made in Console stays until someone edits relay.json.
• A deployment makes the change its preview showed. The preview's calendar shows the change and when it takes effect, or effectiveAt: null when the deployment keeps the current timezone and cancels a pending change. If a day boundary passes, or someone changes the calendar so that publishing would make a different change, publishing fails and asks you to preview again.
• Each environment has its own calendar. Live refuses Console and management changes to it with promotion-required. Live gets test's calendar through a promotion that a person approves. See test and live.
• The audit history records every change, with who made it and why: Project timezone changed for a scheduled change, and Project timezone change cancelled for a cancelled one. Saving what is already in effect records nothing.

When the timezone changes

A change never rewrites history. It waits for the current day to end in the current timezone, and reads show it as pending until then. Saving another timezone replaces a pending change, and choosing the current timezone cancels it.

Where next