startDate < endDate the value should be negative. For upcoming events you say “t minus x days”.
-
Date / Time difference expressions and calculation
-
@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.