Durations and time zones

How Arclo reads a length of time, how it writes one back, and whose clock a scheduled thing runs on.

On this page

Writing a duration

Anywhere Arclo asks for a length of time — a mute, a giveaway, a poll, a cooldown, a temporary role — it accepts the same shorthand.

You typeArclo reads
30s30 seconds
10m or 10 minutes10 minutes
2h2 hours
1h30m90 minutes
7d or 1w7 days
3030 minutes — a bare number is minutes
permanent, 0, or leaving it blankSee below
  • Units may be written short (m) or long (minutes), with or without a space.
  • Parts can be combined in any order: 1d 6h and 6h1d are the same 30 hours.
  • Something unreadable is rejected with a message rather than guessed at.

Blank and permanent are different

Leaving a duration out means use the default configured for this action. Explicitly saying permanent means never expire. Systems that offer both keep them distinct, so a command with no duration cannot accidentally become a permanent ban.

How Arclo writes one back

Durations are printed in the largest unit that says them honestly. Exactly seven days is 7 days, never 6 days 24 hours. Anything that is not a whole number of one unit gets the two largest that fit — 5 years 8 months — because a third would be noise. Under a minute, seconds are the only honest answer.

Absolute times

Where a specific moment is wanted rather than a length — a scheduled giveaway, a scheduled embed, a reminder — Arclo accepts several forms:

  • YYYY-MM-DD HH:mm
  • today 18:00 or tomorrow 09:30
  • A Discord timestamp such as <t:1735689600:f> — which is useful because Discord generates it in your time zone
  • A unix timestamp, in seconds or milliseconds

Whose time zone

Server default
General → Settings → Defaults has a default time zone. It starts empty, and empty means follow whoever is looking — every date the dashboard shows you is rendered in your own browser's zone. Set it only when you want everybody editing this server to see one particular zone.
Per-configuration zones
Anything scheduled carries its own zone — an automation's schedule, a scheduled report, a giveaway. Those always win over the server default.
Member zones
Reminders and birthdays run on the member's own zone, captured automatically the first time it matters. Nobody is asked to configure one, and a birthday lands on their date rather than on the server's.

Daylight saving is handled by the zone, not by the offset

Schedules store a named zone (Europe/London), not an offset, so a rule set for 09:00 stays at 09:00 through the clock change.

Still stuck? Ask in the support server — somebody there has almost certainly configured this before.