Then start a chat and try to explain in german please
-
Date / Time difference expressions and calculation
-
The change off a battery is a manual step. Afterwards set the date in the device. Thats it.
In my case a variable $changedate is set automatically.
You could define a rule that writes the current date/time into a variable that is displayed in the frontend
The problem is how to get the elapsed time from setting this variable to now?
-
How could pimatic know when the battery is changed? Could you provide a sample rule? Would be interesting for others too I think.
Getting the elapsed time? Just display the calculated difference of the datetime device by a variableDevice.
-
What about providing a function to the pimatic core that allows to calculate the difference between two dates.
Thats quite easy. Just tested it:when ... then set $duration = diffDate("2018-01-01", "2018-02-01", "days")
This also works
$last-change = "2018-02-15 17:53:40" when every 60 minutes then set $duration = diffDate($last-change, date(), "days") when trigger:$duration < 1 then ...
For a quick solution just add the function to the VariableManager in the variables.coffee located in pimatic\lib folder. For a permanent solution ask @mwittig to add this to the next pimatic release.
diffDate: args: dateIn1: type: "string" optional: no dateIn2: type: "string" optional: no format: type: "string" optional: yes exec: (dateIn1, dateIn2, format) -> date1 = Date.parse(dateIn1) date2 = Date.parse(dateIn2) diff = date1 - date2 if format switch format when "seconds" diff = diff / 1000 when "minutes" diff = diff / 1000 / 60 when "hours" diff = diff / 1000 / 60 / 60 when "days" diff = diff / 1000 / 60 / 60 / 24 return Math.ceil(diff)
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”.
-
@saxnpaule I am not a pimatic develloper but that looks promising.
@mwittig Can you confirm this? -
@heizelmann said in Date / Time difference expressions and calculation:
@mwittig Can you confirm this?
Yes, I had a similar approach in my mind as I followed the conversation in the past days, but had no time to write a detailed answer as I am currently travelling. Actually, the solution suggested by @SaxnPaule is smart and good to go in my opinion! @SaxnPaule if you file a PR this will be great!
"It always takes longer than you expect, even when you take into account Hofstadter's Law.", Hofstadter's Law
-
@saxnpaule and @mwittig
Thanks a lot I am looking forward to the update and I will test it as soon as it is available. -
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 ifstartDate < 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")
returns1
whilediffDate("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