Date / Time difference expressions and calculation
With the current implementation the call diffDate("2018-01-01", "2018-01-02", "days") yields -1. I find this a bit counterintuitive as, typically, I’d regard the two dates as a start and end date of an interval, i.e. 1.
What do you think?
EDIT: or make the difference an absolute value … In this case the result for the example is 1 no matter which date is passed in first.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
Mhh I think it depends on the usecase.
If you use the difference for dates in past and future to have a countdown or something like that, positive and negative values make totally sense. How many days until the defined date is reached or how many days have already passed.
Also the initial usecase. How many days are gone scince date x and now.
By the order of the attributes you are able to decide whether you want to have positive or negative values.
@saxnpaule said in Date / Time difference expressions and calculation:
If you use the difference for dates in past and future to have a countdown or something like that, positive and negative values make totally sense. How many days until the defined date is reached or how many days have already passed.
That make sense to me. For the other use I’ll simply add the abs() function.
By the order of the attributes you are able to decide whether you want to have positive or negative values.
Yes. However, my suggestion is to change the calculation so, that diffDate(startDate, endDate) yields a positive value if startDate < endDate. Hope, this makes sense
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
Another point to discuss:
Currently diffDate("2018-01-01 8:00", "2018-01-01 0:00", "days") returns 1 while diffDate("2018-01-01 0:00", "2018-01-01 8:00", "days") returns 0. I think it should return 0 in both cases. My understanding is, ine day has passed if the interval is less or equal 24 hours.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
That depends of whether the date has been gone or not. Ceil vs. Round.
In case of the format “hours”, the value should fit.
startDate < endDate the value should be negative. For upcoming events you say “t minus x days”.
@saxnpaule said in Date / Time difference expressions and calculation:
That depends of whether the date has been gone or not. Ceil vs. Round.
Sorry, I don’t get this . Shouldn’t it be “Ceil vs. Floor”?
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
@saxnpaule said in Date / Time difference expressions and calculation:
startDate < endDate the value should be negative. For upcoming events you say “t minus x days”.
Well, yes, you can see it that way.
Another issue may be, some people may expect the value to be 1 or -1 even the time span between start and end is less than 24 hours, but the dates are on different days of the week, say Monday late night and Tuesday early morning. In this case the calculation based on milliseconds breaks. Actually, the matter can get rather complex as shown in the following thread on Joda-Time “daysBetween”. My suggestion is to stick to absolute values based on milliseconds (basically what you have implemented). However, we need to document the behavior clearly.
@Heizelmann What’s your view on this?
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
@mwittig I would expect a rational number like 1.3 days. In combination with math rounding function we could get what ever format wanted.
Alternatively we can use milliseconds.Then we can skip the third parameter. In this case it would be nice we had functions like days(milliseconds) instead of calculating milliseconds / (1000 * 606024).
Another variant for convinience would be diffDate($someDate) which returns the difference to the current time when function called.
@heizelmann said in Date / Time difference expressions and calculation:
@mwittig I would expect a rational number like 1.3 days.
But that means, whether the date is in future or past doesn’t matter, the result would be the same. Thats no good solution.
diffDate(now(), 2018-4-27) would be the same like diffDate(now(), 2018-4-23) >>> 2
@saxnpaule said in Date / Time difference expressions and calculation:
But that means, whether the date is in future or past doesn’t matter, the result would be the same. Thats no good solution.
No, should be signed.
Yes. And now we’re back at @mwittig s question. Which case should be the negative one?
As I understand it, a negative number should be displayed when the date has passed.
@saxnpaule said in Date / Time difference expressions and calculation:
Please see #14
Thanks for pointer. I read the post, but overlooked the important part at the end. Sorry about that.
Regarding the use of Math.round() or Math.ceil() there needs to be a further discussion. I would suggest to use ceil() for positive differences and round() for negative ones.
That means the difference in days will be at least 1 as long as it isn’t <=0.
Half a day after passing the scheduled date, the difference will be -1 days.
By using always the round() function, the difference will be 0, 12 hours before and after the configured “schedule”.
Ok, I see the point, but it in my opinion it is counter-intuitive and may raise a user question even if the behavior is documented. Actually, I am in favor of the point @Heizelmann made as he suggested to return rational number and let the user decide how the result should be handled. However, it tricky as calling round() does not suffice in all cases. It depends on whether the result is negative or positive.
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
@v1per said in Date / Time difference expressions and calculation:
As I understand it, a negative number should be displayed when the date has passed.
So, which one should return -1?
A: diffDate("2018-01-01", "2018-01-02", "days")
B: diffDate("2018-01-02", "2018-01-01", "days")
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
Please use a more realistic example with a reference to the current date.
A: diffDate("2018-04-26", "2018-06-01", "days")
B: diffDate("2018-04-26", "2018-01-01", "days")
In both cases “today” is the 1st parameter. The 2nd parameter is the target/scheduled date.
In case A the date is in the future and the result should be positive. In case B the date has already passed and the result should be negative.
@saxnpaule said in Date / Time difference expressions and calculation:
Please use a more realistic example with a reference to the current date.
A:diffDate("2018-04-26", "2018-06-01", "days")
B:diffDate("2018-04-26", "2018-01-01", "days")In both cases “today” is the 1st parameter. The 2nd parameter is the target/scheduled date.
In case A the date is in the future and the result should be positive. In case B the date has already passed and the result should be negative.
So I think it is right, B should be negativ and A positiv.
