[Discussion] Custom Calculation Attributes results not as expected

[Ryan]

9.0 RC3 clean install.

The attached Tasklist has two calculated custom date fields.

One is a calculation of the 'Due Date' minus 'today'

And the other is a calculation of 'today' minus 'Due Date'

I expected both values to be equal but with an opposite sign.

The number of days from 'today' to the 'Due Date' correctly shows 50.00 D. But the number of days from the Due Date to 'today' shows -48.00 D. I expected it to show -50.00 D.

Hope this is helpful and thanks!

PS: I LOVE being able to show these custom calculation results in the Attributes Entry Pane! Really helpful to see them right there when you are entering other attributes in that pane.

UPDATE:

The issue does not seem to necessarily be related to the 'today' token since I also got the same differing results calculating '3 Due Date Minus Start Date' and '4 Start Date Minus Due Date' ('today' token not used in these calculations). These two also seemed to differ by two days.

I updated the original screenshot and .tdl to reflect this updated observation.

Calculated Attributes values not as expected.png (6.97 KiB) Viewed 566 times

Custom Date Calculations.tdl

(4.13 KiB) Downloaded 37 times

[abstr]

Are the corresponding values in the relevant task view column also wrong or is it just in the Attribute Editor?

[Ryan]

Are the corresponding values in the relevant task view column also wrong or is it just in the Attribute Editor?

The corresponding columns for each field in the Attribute Editor have the same values as they do in the Attribute Editor. Therefore the columns are also wrong.

[abstr]

I also notice that it's wrong in 8.3.14 too so if I won't let it delay the release if I can't fix it by then.

[Ryan]

Not a problem for me Dan in case that's a concern.

[abstr]

Hmm, I'm not sure I completely solve the problem and am therefore wondering if it actually makes sense to be able to subtract a later date from an earlier date.

Practically speaking, 1 day's duration means something very real, but -1D duration is totally meaningless as a measure of something, and that's why you cannot enter negative time periods into Time Estimate/Spent

But. Even as I write this I can see the value of, say, subtracting the Due date from the Completion date, and identifying a negative result as meaning the task was completed ahead of time.

Quite a knotty problem when you add custom dates into a the mix, whose purpose and meaning are completely unknown to TDL, and further when you start to construct nested calculations.

[Ryan]

Suppose you have a custom calculation:
'Start Date' - 'today'

If positive it would show how many days are left until the Task starts.
If negative it would show how many days have passed since the Task started.

And the negative sign would tell you that the task is already in progress.

Both useful results and both from one Attribute for efficiency.

I think the key is getting the calculation right so it is intuitively meaningful and easy to grasp.
===

Additional Note:
I think a custom calculation in TDL involving dates that doesn't make sense is adding them together. I haven't tried that to see what happens but I can't think of any useful purpose for doing that.

I think the significance of that is that all date related calculations in custom attributes will be one date minus another date, which means all the calculations will show the difference between two dates (In days)...a.k.a. the number of days between two dates.

[abstr]

I think a custom calculation in TDL involving dates that doesn't make sense is adding them together.

This is already disallowed.

If positive it would show how many days are left until the Task starts.
If negative it would show how many days have passed since the Task started.

If only it were quite that simple.

1. Let's take a more interesting example: Due - Start, where both point to the same day.
Q: How long is the task?

a) If you say 0D, then how are we supposed to display the task in the Calendar?
b) If you say 1D (which is the correct answer to me) then it can only be because the whole of the Due date is being taken into account.

2. Now let's say that the Due date is one day before the Start date.
Q: How long is the task now?

If we accept b) from before then the answer this time must be 0D, even if intuitively you would say it should be -1D.

And if you argue that the answer should be -1D, then we have a strange situation where 'Due - Start' is never zero, it magically jumps from 1D to -1D (without passing Go and collecting $200)

3. Now let's reverse the calculation: Start - Due, where both point to the same date.

Q: How long is the task now?
Q: And what's your reasoning?

The reason that I've avoided your specific example is not because it is without its own problem, but to highlight that there are more difficult examples all of which must be resolved in a consistent way. We can't have one lot of date calculations (ie Reminders or Custom Calculations or Task Duration) not being consistent with all the others.

all date related calculations in custom attributes will be one date minus another date

Consider:

Calculation 1: (Due - Start) => produces a Time Period
Calculation 2: (Last Modified + Calculation 1) => produces a Date
Calculation 3: (Today - Start) => produces a Time Period
Calculation 4: (Calculation 2 + Calculation 3) => produces a Date

I'm not saying that this represents a meaningful outcome, just that it is possible to construct such a calculation and the answer to the calculation has to be justifiable. ie. it must follow the same specific rules to which all date calculations are subject.

[Ryan]

I do not want to interrupt the excellent progress you are making on tweaking the great new 9.0 Stable release by focusing on this topic at this time. Plenty of time to discuss later. But I had some time on my hands and threw together this table which was an attempt to address what I think may be part one of a two part question about how to calculate and display days between two dates.

Before the calculation is applied it's necessary to know what constraints to apply to the date pairs to avoid invalid results.

So I made up this table of my guesses at the appropriate constraints for each of the built-in Date attributes. The ones in purple are less clear to me than the others, but I took my best guess. Of course maybe they are ALL wrong... you would know much better than me!

Just throwing this out there. I definitely understand there is a lot more going on under the TDL hood than I am qualified to consider and this is a far from simple topic. But hope this might be a helpful piece of the discussion.

This is all just me thinking out loud. You may have already built these constraints in... I am just trying to wrap my mind around this topic best I can. No need to comment if you don't want to or are too busy at the moment as I know you have your hands full. Hoping we can pick this up after things settle down a bit.

Please keep up the great work!

[abstr]

Thx for your comments Ryan.

However, I don't see how this gets us any closer to the problem of how exactly calculating the subtraction of a greater date from a lesser date should be performed consistently across the entire application...

And the 'A >= B' and 'B >= A' constraints don't say how the results of such calculations should be displayed when the constraints are violated.

Neither does it help us with Custom dates.

That's why (IMO) we need to focus on a single method of subtracting dates that does not depend on creating a separate solution for every possible combination and permutation we can imagine.