Scheduled Automation: "tomorrow" / "today" / "yesterday" filters appear to be off by one day

Ideas & Features
1

Summary: Notifications triggered by On Schedule automations with date filters (is tomorrow, is today, is yesterday) are firing one day later than expected.

Setup

  • Entity: Sales task (CRM template)
  • Field: Planned date — type: Date with time enabled (see Screenshot 1)
  • Planned date set to: 2026-07-15T10:00:00.000Z (July 15, 2026, 12:00 local time / CEST)
  • Three separate automation rules, all configured as On Schedule, repeating every 1 day at 00:30:
    • Rule A – “Notify: tomorrow” → Where Planned date is tomorrow (Screenshot 2)
    • Rule B – “Notify: today” → Where Planned date is today (Screenshot 3)
    • Rule C – “Notify: yesterday” → Where Planned date is yesterday (Screenshot 4)

Expected behavior

Rule Expected to fire Expected notification
Notify: tomorrow July 14 at 00:30 “Task is tomorrow”
Notify: today July 15 at 00:30 “Task is today”
Notify: yesterday July 16 at 00:30 “Task was yesterday”

Actual behavior

Rule Actually fired Subject received
Notify: tomorrow July 15 at 00:31 “Fibery Aufgabe morgen”
Notify: today July 16 at 00:31 “Fibery Aufgabe heute”
Notify: yesterday Not received as of July 16, 21:00 —

All three rules fired (or are firing) exactly one day later than expected.

Hypothesis

The Planned date field stores the timestamp as UTC (2026-07-15T10:00:00.000Z). My local timezone is CEST (UTC+2), which means the stored UTC date is July 15, but the local date is also July 15 (10:00 UTC = 12:00 CEST).

However, the automation seems to evaluate the date filter against UTC while the schedule runs in local time — or vice versa. Either way, there appears to be a consistent one-day offset between when the filter matches and when I would expect it to match based on the local date.

Alternatively: does is tomorrow mean “the date value equals [today+1]” evaluated at the moment the rule runs — and is there a timezone discrepancy in how that comparison is made?

Questions

  1. In what timezone does Fibery evaluate is today / is tomorrow / is yesterday for scheduled automations?
  2. Is there a known offset between the schedule execution time and the filter evaluation window?
  3. Is the yesterday rule expected to fire at all, or does it get skipped because the matching window has passed?

Screenshots

(attached: field config, Rule A “tomorrow”, Rule B “today”, Rule C “yesterday”)

Thanks for any help!

2026-07-16_20-59-02
2026-07-16_20-59-021754×1592 210 KB

2026-07-16_21-00-32
2026-07-16_21-00-322190×2932 465 KB

2026-07-16_21-01-09
2026-07-16_21-01-092220×2934 458 KB

2026-07-16_21-01-36
2026-07-16_21-01-362226×2916 461 KB

2

This.
Have you seen our guide on timezones?
Formulas, and other ‘backend’ calculations (like automation filters) know nothing about the user’s local timezone

3

Nope, didn’t thought about it.

Will have a look at it. Thanks

4

As automations are especially at risk due to this dynamic, I wonder if it would be worth mentioning the UTC time in some manner in the automation editor (either as the field value itself, or as an automatic conversion shown next to the field or in a tooltip). This seems to be a recurring challenge mentioned in the forums.

5

We do have plans to introduce the concept of a ‘workspace timezone’ which can be set by an admin (different to UTC) and would be used by all the various affected services.
No ETA I’m afraid though.

6

That’s what I’m talking about :slight_smile:

7

Would it be wise to also add a timezone field on the user? Because then admins could set up individual timezone(s) for use in automations and validation. Defaults to the workspace timezone if a value is not provided.

I think this date issue is what’s holding up everything for us at the moment (incl. scheduling, true reminders, and date-time fields in formulas). Our team spans 3 distinct zones, but then we also have to account for some adjusting to daylight savings.

Off the top of my head, spinning up a local n8n instance seems the least effort workaround, but then we would be leveraging two systems running in parallel, and maintaining one in-house with no dedicated developer.

8

I’m not sure what use there is in adding a timezone field per user.
Automation rules are not tied to a user, so there is no way to attribute a user’s timezone to an automation.
And I’m not sure how timezones could be used in validation rules for any meaningful use cases. Do you really want a validation rule to block a change if that change was made by a person in one timezone, but not block for someone in another timezone?

Ultimately, anything timezone-related needs to contend with the reality that the data stored in the backend is the same for everyone. Sure, you can choose to show the data differently on the UI from person to person (as we do for date time fields) but formulas/automations/validation can’t reasonably behave differently from user to user.

Maybe I’m missing something, so perhaps a few concrete use cases would help.