I guess this is more of a question of feasibility. The main reason the Now() is not in formulas is because it would need to update every second, resulting in a lot of server load. I’m wondering if its feasible to have Now() be recalculated every minute, of if that would be too much as well. I’m running time tracking in fibery, and while it does calculate the total time after I stop the tracker, it would be nice to see the time as the tracker is going as well.
Thanks!
I wonder if this is more of a frontend UI (display) matter than one of formula calculations.
In other words, the option for a relative time/date display format that delegates this to react on the frontend to show the date/time in relation to now with determined stepping such as second, minutes, hours, days, etc.:
Would that not address your case, without formulas?
Imagine a user wants this formula:
If(Now() > DueDateTime, "WARNING!", "Relax))
How do you suppose your proposal would solve this?
Hi Chris, Thanks for your response.
I was referring to @RonMakesSystems use case, but I believe that even your example has the same two routes to a solution. Since using now() in a server-side formula is almost always both scary (e.g. if other formulas depend on a now-based formula), and hacky (e.g. now, but really now every 15 seconds, not now always).
Other processes/fields depend on it, in which case it would be best to handle using Rules with “On Schedule” trigger, since mentally it communicates both the non-live aspect, and the heaviness of such a use case, and therefore should hopefully lead an architect to only choose when when absolutely necessary.
Other processes/fields do NOT directly depend on it, for example the strings “WARNING!” or “Relax”, in which a derived (transform) formatting (i.e. delegation to React to use the formula to determine display format, not limited to colour or bold only, but also the actual display value) would be the the approach that comes to my mind.
Even though the developer in me would love this, I would not consider this a priority feature, due the difficulty to solve its mostly negative UX impact because of how complex the UI would have to be.
In theory the approach would be giving the architect the option to have client-side UI transform formulas that transform the current output of the field into something else which has no bearing on the database, and is only visual. This is an extended version of something like Coda’s formula-in-conditional-formatting approach. Though in Coda’s case practically everything is done on the client side in the UI (a major negative in terms of scalability of database size) , which is presumably why they have such robust use of Formulas everywhere.
Here is an example of the date field component where this would start, but the rest would be UX downhill 
:
If I have a Project DB with 1:m relation to Tasks, I might want a formula
Tasks.Filter(Now() > [Due Date])
This is not currently possible.
I’m not sure how this could work with a frontend transformation/formatting solution in a performant way.
And using rules as a solution would rely on updating an editable field, which is not usually desirable.
TLDR there is definitely a need to have more granular date comparisons in formulas than is currently possible i.e. supporting Now() as well as Today()
But I don’t see it getting addressed any time soon 
You are correct, but again going back to the original use case of @RonMakesSystems I would delegate that to the frontend, unlike your filtering use case, which is indeed more complicated.
I was thinking about it from a data perspective. Seeing the reports of the minutes done today without needing to stop the task to see the amount of work done.
But I just did some testing, and I see that “Now()” exists in reports!! So that solves that aspect of it.
The other side is indeed just UI, where when tracking a single task, it shows the number of minutes tracked in the task ticking up. (Lots of other task tools have a time logging feature). This would indeed just be for prettier UI.
Edit:
What might be an interesting new field is a “front-end formula” which just calcuates on the front end instead of on the back end. A big advantage of this would also be around permissioning. Formulas don’t respect access control right now, and a field of that type could help solve that. Disadvantage is that you can’t use it automations or backend formulas, but each thing has a different use case! (or a toggle in the existing formula field to “Calculate on front end”)
Hi @Chr1sG, I have given a bit more thought to the scenarios that would need your formula above, and find that many (not all) of the use cases behind such a formula could be handled using the best fit from:
I think for a platform like Fibery, there is no non-hacky way to implement server-side now() in formulas, as evidence by Airtable’s own convoluted approach to now() from whose docs I quote:
While similar to the TODAY() function, NOW() returns the current date AND time.
This function updates when the formula is recalculated, when a base is loaded, or otherwise roughly every 15 minutes when a base is open. If the base is closed, it will update approximately every hour only when the base has time-dependent automation triggers or actions, or sync dependencies.
While I know that Coda loads the entire “doc” (“space” in Fibery) into the browser, my research shows that Notion does something similar but with less full reliance on only the browser. I could very well be mistaken, but I believe that this is why they both can offer now() in their formulas, since it is UI-evaluated.
