# Scheduled Automation: "tomorrow" / "today" / "yesterday" filters appear to be off by one day **URL:** \ **Category:** Ideas & Features\ **Tags:** automations\ **Created:** [July 16, 2026, 7:38pm UTC](https://community.fibery.io/t/scheduled-automation-tomorrow-today-yesterday-filters-appear-to-be-off-by-one-day/11080 "2026-07-16T19:38:17Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![boris1ab](https://avatars.discourse-cdn.com/v4/letter/b/8491ac/32.png) [@boris1ab](https://community.fibery.io/u/boris1ab)\ **Post date:** [July 16, 2026, 7:38pm UTC](https://community.fibery.io/t/scheduled-automation-tomorrow-today-yesterday-filters-appear-to-be-off-by-one-day/11080/1 "2026-07-16T19:38:17Z")
**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](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/b/b919a015fb1686b4377d4d05879e343ce933f349.png) ### ![2026-07-16_21-00-32](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/a/a0bfba657767b95c99dfbe613a032d19c769b723.png) ### ![2026-07-16_21-01-09](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/5/568614e8105fc06870911f94b24f3a266167326c.png) ### ![2026-07-16_21-01-36](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/d/d293f310f5260886ae7fd5f6c99dc155030c718e.png) ### ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [July 16, 2026, 8:20pm UTC](https://community.fibery.io/t/scheduled-automation-tomorrow-today-yesterday-filters-appear-to-be-off-by-one-day/11080/2 "2026-07-16T20:20:22Z")
> [@boris1ab](#): > > However, the automation seems to evaluate the date filter against **UTC** while the schedule runs in local time — This. Have you seen our guide on timezones? Formulas, and other ‘backend’ calculations (like automation filters) know nothing about the user’s local timezone > **[Timezones](https://the.fibery.io/@public/User_Guide/Guide/Timezones-41)** ---
**Author:** ![boris1ab](https://avatars.discourse-cdn.com/v4/letter/b/8491ac/32.png) [@boris1ab](https://community.fibery.io/u/boris1ab)\ **Post date:** [July 17, 2026, 3:46am UTC](https://community.fibery.io/t/scheduled-automation-tomorrow-today-yesterday-filters-appear-to-be-off-by-one-day/11080/3 "2026-07-17T03:46:51Z")
Nope, didn’t thought about it. Will have a look at it. Thanks ---
**Author:** ![Michael\_Ichter](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/michael_ichter/32/9931_2.png) [@Michael\_Ichter](https://community.fibery.io/u/Michael_Ichter)\ **Post date:** [July 17, 2026, 6:33am UTC](https://community.fibery.io/t/scheduled-automation-tomorrow-today-yesterday-filters-appear-to-be-off-by-one-day/11080/4 "2026-07-17T06:33:56Z")
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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [July 17, 2026, 6:52am UTC](https://community.fibery.io/t/scheduled-automation-tomorrow-today-yesterday-filters-appear-to-be-off-by-one-day/11080/5 "2026-07-17T06:52:56Z")
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. ---
**Author:** ![Renato\_Carvalho](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/renato_carvalho/32/11001_2.png) [@Renato\_Carvalho](https://community.fibery.io/u/Renato_Carvalho)\ **Post date:** [July 18, 2026, 1:57am UTC](https://community.fibery.io/t/scheduled-automation-tomorrow-today-yesterday-filters-appear-to-be-off-by-one-day/11080/6 "2026-07-18T01:57:04Z")
That’s what I’m talking about 🙂 ---
**Author:** ![AdVhPkgKad](https://avatars.discourse-cdn.com/v4/letter/a/7993a0/32.png) [@AdVhPkgKad](https://community.fibery.io/u/AdVhPkgKad)\ **Post date:** [August 12, 2026, 12:02am UTC](https://community.fibery.io/t/scheduled-automation-tomorrow-today-yesterday-filters-appear-to-be-off-by-one-day/11080/7 "2026-08-12T00:02:58Z")
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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [August 12, 2026, 2:05pm UTC](https://community.fibery.io/t/scheduled-automation-tomorrow-today-yesterday-filters-appear-to-be-off-by-one-day/11080/8 "2026-08-12T14:05:25Z")
> [@AdVhPkgKad](#): > > 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’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.