Skip to content

Time expressions

Some steps ask you when to look: which tasks changed since when, what arrived in Memory in the last day, which calendar events fall in a window. You can answer those with a literal date — 2026-08-05 — but then you have to keep changing it, because tomorrow that date is wrong.

Instead, write what you mean: yesterday, -7d, today. Routario works out the actual date at the moment the step runs. A flow you set up in March still asks the right question in November, and nobody has to remember to update it.

This matters most for Agents. An agent decides for itself what to look up, so it fills these fields in as it goes. Asking it to work out today’s date first is asking for the one mistake it reliably makes.

WriteMeans
nowThis exact moment
todayMidnight this morning
yesterdayMidnight yesterday morning
tomorrowMidnight tomorrow morning
-7dSeven days ago
+1wOne week from now
-2hTwo hours ago
2026-08-05Midnight on that date
2026-08-05T14:30:00+02:00That exact moment

Offsets need a sign and a unit: h hours, d days, w weeks, m months, y years. So -7d, not 7d.

StepFields
List tasksCreated after, Updated after
List memory itemsCreated after, Created before
List calendar eventsFrom, Until

All three read the same vocabulary, so you don’t have to remember which step wants which style.

Your timezone decides when “today” starts

Section titled “Your timezone decides when “today” starts”

Day words land on midnight in your workspace timezone, not UTC. If your workspace is set to Europe/Prague, today means 00:00 Prague — which is 22:00 the previous evening in UTC. That’s almost always what you meant, and it’s why a “what happened today” report doesn’t quietly include last night.

Set your workspace timezone under Settings. It’s the same setting that drives when scheduled flows fire.

If you write something Routario can’t read — next week, since yesterday, 7d without its sign — you get an error naming what you wrote:

'next week' is not a time expression. Use one of: now, today, yesterday,
tomorrow, a signed offset like '+1d' / '-2h' / '+1w', a date like
'2026-08-05', or a full ISO 8601 datetime.

This is deliberate, and it’s the most useful thing on this page.

The alternative would be to shrug and return nothing. But “no results” is a perfectly ordinary answer — an empty list looks exactly like a quiet week. A report built on top of it reads as confidently correct while being silently wrong, and nobody catches it, because there’s nothing to catch. A step that stops and tells you the filter was unreadable costs you thirty seconds. A step that returns a plausible empty answer can cost you a fortnight of not chasing something.

List tasks and List memory items stop the run outright. List calendar events fills in its error output instead and returns no events, so a flow can carry on and skip the calendar section — check that field if you branch on it.

Leaving a field blank is not an error. It just means “no limit on that end”.

Worked example: what changed while I was away

Section titled “Worked example: what changed while I was away”

A flow that reports everything touched in the last week, run every Monday:

  1. List tasks — set Updated after to -7d.
  2. List memory items — set Created after to -7d.
  3. Send email — summarise both.

Nothing in that flow needs editing, ever. Change the schedule to daily and switch both fields to yesterday; change it to monthly and use -30d.

Both deal with time, but they work differently:

  • A time expression is a value you type into a field: yesterday. The step reads it.
  • A template variable is a value you pull in from elsewhere: {{ now.date }}. Routable into any field, on any step, and it renders as text.

Where a field takes a time expression, prefer the plain word — it’s shorter and it says what you meant. Reach for {{ now.date }} when you need today’s date somewhere that isn’t one of these fields, like an email subject line.

Both are safe to combine: a field given {{ now.date }} receives a real date, which is valid input here too.