As shown, I’ve set this automation to kick-off every Friday
…except June 14th is a Saturday
The resulting actions are therefore late by a whole day and are wrong
1 Like
What timezone are you in?
UTC +10
I wouldn’t have thought it’d matter considering how the automation is worded
1 Like
The way it works is it converts it to UTC and saves it in the Fibery backend as UTC. So I think something in the conversion isn’t working as it should…
No idea. Some funky stuff is going on here. Also noticed that the time picker starts from 10:00 in your timezone… then anything after 00:00 is set to the next day. Funky.
For now you can just set it to thursday in the UI and then itll pick friday?
Should still be okay after its fixed because it’ll be saved as the right thing in their back end i hope.
That seems to be the bug. Rather than starting at 00:00 and going through to 23:30, the moment time wraps in the selector it begins treating everything after 00:00 as the following day.
Bump. This is still an issue for our team.
Email notifications (reminders) are being sent a whole day out—kind of pointless for reminders, no?
I figured this as UTC is behind. I have to factor this in. Automations don’t work for date comparisons, even if the date is stored as a Date and not a Datetime (5 Nov =/= 4 Nov)
I’ll do this by instead of relying on a schedule, relying on a reminder trigger on a per-user basis, by storing a timezone against the user, and using a formula with a rule that triggers.
EDIT: also found this was not possible, since Today() only calculates ONCE, and there is no way to use the current time in formulas.
Looks like I’m setting up a local n8n instance… such a shame.
Correct. This is because the formula service would be overloaded if it had to recalculate every second (minute?) of the day.
In general, date comparisons should work fine (if comparing a date with a date) but comparing a date with a datetime requires typecasting, which often gives unintuitive behaviour.
And indeed, Fibery uses UTC on the backend, which is where formulas are calculated.
2 posts were split to a new topic: GCal all day events syncing incorrectly
I noticed this last week but was able to work around it. I was creating a chron job that needs to run once a year on daylight savings “day”.
I wanted the automation to run early on Sunday mornings but it was almost as if the Week day picker was treating Saturday and Sunday as the same option. So I opted to schedule the automation on Saturday evenings around 11pm.
1 Like
If the automation filter is set to “where date is today”, it’s wrong. Every time. Period.
Not once has any scheduled automation I’ve set up in this app ever ran on time.
Tell me if I’m not understanding this correctly: Today in this context will always be midnight UTC, which when returned and cast to a datetime in the front-end (displaying MON DD, YYYY HH:MM) will apply the offset, e.g., Oct 30, 2025 11:00 ← UTC offset.
The date field on any entity, when stored, will NOT apply this UTC reverse conversion. It was picked out of a picker by the user, and is stored as the day they chose AS UTC ALREADY.
Because their timezone is not applied, it means when the users pick 6 Nov 2025 (thinking it means their timezone) they’re actually picking 6 Nov 2025 in UTC.
Which means, yeah, the comparison is technically correct, but only because the system is incorrectly assuming that users will even know what UTC is, how it affects things, and then their calendars will be out a whole day just to get automations to run correctly? Seems like a huge oversight.
Which is why if I schedule something to run at 12PM it will work, no problems, but picking any time before 11AM (due to the 11 hour UTC offset) will cause this out-by-day error.
This is just not acceptable for our business. Midday is half-way through the working day for the people who need these notifications to run in a timely fashion. Sure, I could just keep this in the back of my head each time I make an automation rule and choose “Date is tomorrow” instead if the time is < 11AM, but that’s super janky and error-prone.
So yeah, there are two issues here that need addressing.
And regarding this, everything at the UTC changeover grinds to a complete halt already (formulas pending, automations stalling, user experience down the toilet).
Multiple times employees have come to me and complained that what they’ve entered has not saved, or the automations/buttons I’ve set up haven’t run properly (formulas that have nothing to do with dates are also impacted, e.g., the name field), and I put the blame solely on the server load.
Not trying to be a complete dick about this, but is there not a more effective way to make sure the formulas are correct? e.g., JIT processing
This whole debacle has wasted days of my time in meetings with management, documenting bug reports, testing edge cases, looking for alternative solutions…
There are a couple of topics getting intertwined here, so I will attempt to untangle them:
Formulas
A formula field does not support Now() for performance reasons. This is not directly related to timezones.
Today() is supported in formulas, and recalculation does indeed occur at midnight UTC. Formula recalculation is done on the ‘backend’ where everything is in UTC.
In principle, it might be possible to define a different recalculation time per workspace, so as to spread load.
We have in fact considered allowing admins to define a ‘workspace timezone’ for a variety of reasons, and if we did, it is quite possible that we could switch formula recalculations to run at midnight in the ‘workspace timezone’ (or maybe even a time of day of the admin’s choosing).
Correct. Although I don’t know of many cases where casting Today() to a datetime is useful.
I don’t understand quite what you are saying here.
A date field (i.e. not a datetime field) does not have any time component, so if a user picks 6 Nov 2025 on the UI, it is stored as 6 Nov 2025 on the backend. There is no time component, so they are not picking 6 Nov in UTC, nor are they picking 6 Nov in their local timezone.
Unless/until a formula calculation involving Today() or typecasting dates to datetimes comes into the picture a user should never need to know about UTC.
Now, imagine there is a formula DateField < Today().
This will get recalculated any time either of these values change. If DateField value is set as 6 Nov 2025, then the value will become true shortly after midnight (UTC) on the 7th Nov 2025 (which is when the value of Today() changes)
Depending on where you are in the world, this field value may appear ‘incorrect’ if you look at this formula field result during certain hours of the day.
If we introduced a ‘workspace timezone’ then this problem might go away for the users who are based in the workspace timezone.
Sidenote: there could only be one ‘workspace timezone’, so in the situation where multiple users are spread across timezones, it would still be impossible to keep everyone happy (unless we did some serious technical changes to how formulas work).
Scheduled automations
When an automation is configured to run on a schedule, it is intended that everything on the UI is correct according to the user’s timezone. In other words, if you set an automation to run at 10am every day, it means 10am local time.
Behind the scenes, some stuff is converted to/from UTC, but this should all be hidden from the user.
Of course, if you want an automation to run on a Friday ay 9am, that’s what it should do.
Based on the first image you shared (@AdVhPkgKad) it appears that you have uncovered a bug. We are still looking into it and will let you know when a fix is rolled out.
This behaviour is not intended, nor is it an unavoidable consequence of the way the system is designed. It should not happen.
Automation scheduling is unrelated to formula fields
However, this topic has taken a tangent into a discussion about formula fields. Although interesting, it is not directly relevant.
It may be that the bug, when discovered, will be traced back to some code that one of our devs has written which does not correctly take into account timezone effects, and thus has some coincidental connection to UTC, etc.
Note also, the issue that @Renato_Carvalho is having with Google Calendar is a completely unrelated bug, which we are also looking into, as I wrote.
On the contrary, formulas are essential to automations
And I may have made myself not clear, or muddied the waters with what I was saying. That’s my bad. I’m just a little frustrated, and I find it hard to explain when elevated.
Here’s pictures to explain what I mean.
I want automations to run for our task management system, at 7 AM our local time.
I go into the Users db and set up an automation rule to run on schedule.
- Users are assigned as responsible for the task
- Tasks have a due date (not datetime)
- I have a filter formula where tasks due date = today ← this breaks
Before 11 AM, it isn’t considered ‘today’ since the calculation hasn’t run (it is not yet midnight UTC). The list is therefore exactly one day behind when it is calculated, and the automation runs with yesterday’s tasks.
I try switching it up.
I go into the Tasks db, set up the same automation rule.
I then use the filter field inside the automation (Add Filter for Tasks).
This still fails. The calculation is incorrect because when it runs at 7AM, it still has yesterday’s date when compared to the value stored, not meeting the filter requirement to trigger the event.
Which I why I incorrectly said they’re picking a UTC date, but for all intents and purposes it is treated as such, literally everywhere it is feasibly used.
Yes, and this does not require formulas. If it isn’t working for you, then we should fix it.
Are you talking about a filter condition for the scheduled automation?
It sounds like there might be two (or more 
) things going on:
- the scheduled automation is not running at the right time (= a bug, evidenced by the very first image in this topic)
- when the scheduled automation is running, the tasks you want/expect to be included in the automation are not the ones that are actually included
- something else ??
I thought this topic was about the first issue.
But indeed, if the second issue is also occurring, this may well be a side-effect of how ‘today’ is defined in Fibery.
At 7am in Australia, on the 6th November, as far as Fibery backend is concerned, ‘today’ is the 5th November, and there’s currently no way to change that.
I’m not sure whether I can agree with this though:
If a user sets a date field value to be 6 November 2025, then a table view which has a filter Date is today should work correctly for each user according to their timezone. These data view filters are ‘frontend’ and are ‘locale-aware’.
For users who never write formulas or define automations, the backend quirks related to UTC should never occur to them.
Yes, there are two issues. I thought I made that clear. The first when the time picker influences the day picker and wraps over to the next day. We’ve established that is a bug.
The second is the way Today() is calculated with respect to, and when compared to, stored date fields.
The stored date value is 2025-11-06. Before 11AM today, when the automation ran, it was unsuccessful, because Fibery was still 2025-11-05 UTC. Afaik, from what you’ve mentioned, this cannot be circumvented as it is core to how the formulas and filters work.
The only workaround is to be very actively aware of how this functions, and write filters/formulas etc. to avoid it. This means handling all automations running before 10/11AM our time (DST) differently.
Let’s break it down.
When I have a list of Tasks associated to a User, they have Due Dates.
I can write a formula to get “all dates due today” as a list of relations.
But as we have established, this does not work: it will show everything due YESTERDAY before the UTC rollover, because the formula relies on Today(). Meaning that the field itself is completely correct in terms of UTC, which is why it’s “effectively” only useful when doing UTC comparisons.
The table/list filters seem to be different though. I don’t know why it works properly for those.
I understand what you are saying, and have come to the conclusion that I don’t think Fibery will be able to do what I want it to. I may need to write a n8n automation for this.
If I understood this correctly, it would also affect views where the filter is “Due date = Today”, no?
The Formula Today() works the same as the no-code filter Today in views?
Or does it just work the same way in automations because it’s on the backend and the views are different and are on the front end and hence can be calculated per user?
I wonder if just getting a notification to check a view every morning would be any helpful. @AdVhPkgKad
This topic is quite fascinating. Lots of details and considerations when it comes to timezones and it’s quirks.
I had a idea at some point to implimented timezones myself in fibery by adding an “Hour Offset” field per user. Then transfer the date to store as the time for the user and not as UTC. But still not sure if this fix the “Today()” issue…
Nope.
Try it. Change your timezone on your computer and look at what happens to a view where the filter is Due Date is today.
Correct.
There is currently nothing a user can do to make Today() update at any time other than midnight UTC.
It is possible to add a timezone offset such that a formula like ToText(datetime) gives the ‘correct’ result (assuming that every user is in the same timezone) but there’s no way to force a formula (or scheduled automation filter) to believe that Today() is anything other than its UTC value.
When some users don’t want to touch the app with a ten foot pole unless prompted, it means everything.
We set tasks in the head office for people out in the field. They’re not logged-in all the time, and don’t have access to desktops.
When the task is set (assigned to the user) they get a notification. If they’ve enabled emails (most haven’t, sigh), they will get an email to their phones, too.
This is why it’s important to us: if we asked them to do something a fortnight ago, they’ll forget about it since they have so much on their plates each day. Having a reminder “get this done today, urgently!” as they’re eating breakfast is the best way to get them to focus, without calling them.