meteohub.de

I use this command to calculate how many days have passed since the last rainfall:

{*([epoch]-[rain0total-nonzerotime=epoch])/86400:--*0}

But it says 1 day already after 12 hours.

If it rains 19pm then it says 1 day the next morning at 7am

Is there somebody that can figure out how to modify the command so it first says 1 day after 24 hours?

Regards
Michael

That expression was derived in terms of whole "days" (as such), 24 hours might be 1 day but starts to become a little different as the original expression outputs an integer number of whole days rounded. Being reliant on the epoch determination (in seconds from 00:00:00 UTC Jan 1, 1970) then there also becomes a time zone issue/offset depending on the local time zone difference relative to what is the day (midnight or similar time) trigger you are expecting.

Also are you referring to "whole" days or specifically 24 hours, like what do you expect if the last rainfall was @ 23:58? Is 00:02 the "next day" deemed to be 1 day since the last rain? Lot of what if scenarios depending on when within a "day" (as such) the last rain occurred.

Thanks for the answer.

I thought 24 hours after last rainfall would trigger "1 day".

86400 / 60 / 60 = 24

Is the answer that unfortunately it isn't possible to calculate this?

I think it's more to do with the expectation (as such) rather than the determination. Yes 24 hours is 1 day but is more a reflection of a UTC time period (epoch) rather than a date/day corrected to your time zone relative to the last epoch it rained compared to your local time. Now if you lived in a +/- 0 Time zone, UTC midnight = Local midnight which is easier but there is still the rounding in managing what a day is.

Now if you wanted Hours since last rain. no problems, hours don't have a date/day reliance as right at this point in time, your local time is different to UTC time depending on your Time zone and that difference and time of day basically dictates if today's date and the UTC date could or could not be the same.

In the expression to refer the bit on the end *0) is simply providing a whole number and could be rounded up or down. For example 203.76 hours since last rain is 8.49 days (rounded to 2 decimals) which in that expression will be 8 days (rounded), at 204.24 hours then it's 8.51 days and rounded it becomes 9 days over a time difference of less than 30 minutes. Now considering this function is continuously being determined throughout each day there will be quite different results during a single day since the last rain.

If you changed the *0) to *1) or *2) then you would get the number of output days (as such) rounded to 1 or 2 decimal places and that would pull the difference in tighter but there could still be a difference (in days) that appears illogical? You are seeing this "1 day already after 12 hours" due to this rounding in addition to the points outlined above.

Thank you for the explanation.

If I understood you correctly, it is possible to calculate how many hours it has been since last rainfall?

Could you divide that with 24 and then get the days?

If it is 23 hours since last rainfall: 23 / 24 = 0,958 (0 days)
If it is 25 hours since last rainfall: 25 / 24 = 1,042 (1 days)

Yes no problem calculating hours, just change 86400 (seconds in a day) to 3600 (seconds in an hour) but that still doesn't solve the rounding.

See how you go with using {*([epoch]-[rain0total-nonzerotime=epoch])/86400:--*t} which will provide a non-rounded truncated integer value in Days, where # of Days is based on a 24 hour interval period and there is going to be what appears like illogical results but without structured logical code there is not much way a simple simple numerical expression can be handled?

For example say last rain was at 23:58 on July 12, at 23:57 on July 13 should give 0 Days, at 23:59 on July 13 should give 1 Day, at 00:02 on July 14 gives 1 day as will every other period on July 14 up until 23:57 (July 14). If that is what you expect then that should work?

I have changed *0 to *t and looking forward to see what happens.

Thanks for your help.

Regards

Michael

It works now - It says “1 day” after 24 hours.

I use it on Twitter that I update every hour.

Is it easy to change the calculation, so it displays number of hours since last rainfall?

Then I could write:

Days since last rainfall: 2 days (49 hours)

For the days component you could also use *1 which would provide an additional time frame breakdown within the day.

Currently have this expression on a test rig and this morning it rained so with *t currently outputting Days since last rain: 0 days, continuously, 12 hours after the event Days since last rain: 0 days, at 5am tomorrow morning, the day after and 23 hours on from the event will still be showing Days since last rain: 0 days which doesn't actually indicate the rain period within the last 0 days, could be 2 minutes ago, could be 23+ hours ago

Using *1 then right now my rig would show Days since last rain: 0.5 days, at 5am (tomorrow morning, next day) will be something like Days since last rain: 0.9 days, around 7am tomorrow morning something like Days since last rain: 1.1 days etc etc

Just a thought

I think this is the conversion table:

0.1 = 2.4 = 2t 24min
0.2 = 4.8 = 4t 48min
0.3 = 7.2 = 7t 12min
0,4 = 9.6 = 9t 36min
0.5 = 12.0 = 12t 00min
0.6 = 14.4 = 14t 24min
0.7 = 16.8 = 16t 48
0.8 = 19.2 = 19t 12min
0.9 = 21.6 = 21t 36min

I have changed it to *1

Now it says: 1.2 days (1 day, 4t 48min)

Maybe 1.2 days is good enough - if people understand that 0.2 is nearly the same as 5 hours

Here in Denmark we have had less rain than normal. The weather guys were starting to inform, that now we haven’t had rain for 12 days etc.
Therefore I would like to include days without rain in my Tweets.