When using durations it’s very nice to be able to measure the time between two dates.
For example, imagine I am supposed to finish a task by Thursday and today is Monday, this would give me 3 days to finish the task. If instead I was supposed to finish by this Monday and today is Thursday, I’m late, I should have finished 3 days ago.
So far, Coda works perfectly for this task: ToDate(Today() + 3) - Today()) => 3 days ToDate(Today() - 3) - Today()) => 3 days ago
Now, imagine that I finished the task 3 days late, and that I want to keep track of the fact that I was late finishing the task (perhaps I’m trying to improve my forecasting ability by looking at past tasks). So, I create a table that looks something like this:
Notice how confusing that is, the “Timeliness” column says that I finished 3 days ago, which is not true at all. I finished 3 days past the deadline.
Were Coda to change this text to instead say 3 days past it would make sense in this context, unlike 3 days ago. Furthermore, “past” preserves its meaning in other contexts as well:
I’m late, I should have finished 3 days past. ToDate(Today() - 3) - Today()) => 3 days past
I don’t understand why “past” is better than “ago”.
“Ago” is totally proper here, and I’d even argue it’s the best fit.
Your link refers to the difference between “passed” and “past”, it doesn’t say anything that “past” is better than “ago”.
UPD: For your specific case where you use the duration as indication of “completed X days ahead of time / past the deadline”, indeed it makes sense to use different phrasing. You can construct something like that with formulas. But I don’t think that the phrasing should be changed universally. Many people use the Today() - date formula specifically to get that the event/deadline was “x days ago”.
I agree “ago” is a better fit than “past” in the case of “I finished 5 days ago”, but whenever the duration that you’re talking about is not relative to Today() then “ago” has a bad fit. I agree we would lose something by replacing “ago” with “past” but I figured it would be the easiest solution that is marginally better. I run into this issue frequently enough that using durations are actually problematic because the meaning is incorrect.
E.g. The item should have arrived on 5/10 but it actually arrived on 5/15. How late was it? 5/5 - 5/10 = 5 days ago. Should it have arrived 5 days ago? No, it arrived 5 days past the arrival date.
You’re right about my link, here’s a link to complete that thought: essentially ago == passed. Swap “passed” for “ago” and the prior link is relevant.
Perhaps Coda can intelligently detect if the duration is relative to today i.e. if Today() is in the subtraction, in order to decide to use “past” or “ago”. This would fully cover the use cases where “ago” makes for better phrasing.
E.g. Today() - 5 => 5 days ago 5/10/2019 - 5/15/2019 => 5 days past 5/5/2018 - Today() => 474 days ago
TL;DR: I’d prefer a more agnostic minus sign for negative duration.
I’m not a native speaker but it seems obvious that ago only applies when comparing with the present. I’d personally prefer earlier/later or before/after as more neutral ways.
Even if you’re dictionary-pedantic and says that ago the right word for any date in the past, explain this:
In short, Coda prints any negative duration as ago.
But here’s the thing: we’re looking at how Coda words something that is heavily contextual.
Here’s another case:
Now, none of the words mentioned so far are proper to describe the amount of time you spent over/under the estimate. I can think of less/more, over/under, faster/slower(?).
There are so many use cases that the most sensible would be to just print a minus sign, then leave the choice of words, if needed at all, to the user.
The only way I can think of that working is if you interpret past as “past the mark”. But that’s a whole different meaning than the one you argue for in your previous posts.
In fact if you go that way you could argue to use past for any negative number at all, not only duration.
But even speaking strictly about duration, past can’t possibly be flexible enough to cover all use cases.
Just another example. If your business logic is such that Diff adds up to a time bank, I expect the results to be X hrs or -X hrs in the bank.
In this case past makes as much sense as ago (none in my view):
I think it’s the same to what I was saying before, but it’s likely that I’m communicating poorly. I’ll do both of your examples in the terminology I recommend, with both before and after examples so that you can compare:
We want to know how much Clocked In is over or under the Target number of hours. In this case, it was 16 hours under, but we both agree that 5 hours ago makes no sense in this context.
Now, if we change the text to past instead of ago it makes sense. The hours they clocked in was 5 hours past the target number of hours. 5 hours past 20 hours = 25 hours.
I don’t think that changing formulas to make something work is proof that it isn’t flexible enough.
By example, managing data in tables is a notably difficult and limiting paradigm that requires changing the way you think about the problem. It’s necessary, however, because it’s faster, and allows for more powerful relationships between data. No one is saying, “Coda shouldn’t use tables because they’re limiting”, because we understand that they are the best tool currently available for the job.
A great tool does not map onto every problem, but rather every problem can be mapped onto a great tool. It’s up to the user to perform the problem transformation such that it applies to the tool’s capabilities. (The more consistent the problem transformation, the easier someone will learn the tool.)
Coda uses FormulaMap rather than a for loop, which has completely different syntax, limitations, context, and abilities that a for loop does. But the measure of FormulaMap is not how similar it is to a for loop, but rather whether the problem you would have solved with a for loop can also be solved with FormulaMap and how difficult it is to make it work.
In the same way, the measure of any other change should be whether the solution is useable and discoverable. Will the user get the feedback they need to find the right direction to perform the subtraction? Yes, they’ll try it one way, find it doesn’t make sense and try it the other way. Will it give them a sufficiently useable phrase that can be easily understood? Yes, ‘15 days past the deadline’ is terminology that’s used all the time.
I know this is an old thread, but I’m new-ish to Coda and find “days” and “days ago” confusing too.
What makes more sense to me is simply a positive number instead of “days” and a negative number instead of “days ago.”
I found an easy fix I want to share in case it’s not already universally known:
I have a column called “deadline” that’s populated with dates past and future.
I have another column called “+/- deadline” with this simple formula:
thisRow.Deadline-today()
This still gives out values that include “days” and “days ago”…so to overcome that, I just changed the format of the column to “Number 123” and output is positive and negative numbers.
)