$span(day_delta=30).length.day.format("%d") yields 29 days

[michael.k...@gmx.at]

Hello,

$span(day_delta=30).length.day.format("%d")

yields "29 days". I think this is because of the DST change in the station's time zone which was about three weeks ago, it used to show "30 days", and I am confident it will again show "30 days", after the DST change is more than 30 days ago.

How would "DST-safe" expression look like?

[gjr80]

Quite likely will fix itself once beyond 30 days since DST changeover given that .length simply takes the difference in the start and stop timestamps of the span. Unfortunately no simple or neat solution given WeeWX is not daylight saving aware. 

But I wonder what really is  the issue here? I expect the $span .length tag to show the 'wrong' result, but I suspect the corresponding $span.rain.sum tag used to display the last 30 days rain will in fact be correct. So I suspect the issue is just with the label. You are manually setting the day_delta to 30, why not simply hard code the label or use a little cheetah python and set a variable to 30 and then use that variable in the $span(day_delta=xxx).span.sum tag to produce the last 30 days rain and then again to display the span in days. I expect that '24h' and '72h' would suffer from similar problems, though probably not as noticeable due to the short elapsed time until the issue resolves itself for those spans.

Gary

[michael.k...@gmx.at]

 > Unfortunately no simple or neat solution given WeeWX is not daylight saving aware

Well, looking on how the template is coded, the simple solution is such a no-brainer, I didn't even think of it. And that although you proposed it, you wrote the above, that there ist no simple solution: "So I suspect the issue is just with the label. You are manually setting the day_delta to 30, why not simply hard code the label" which is the simple solution, so thank you for that.

https://github.com/brewster76/fuzzy-archer/blob/master/skins/Bootstrap/rain.html.inc#L20

But anyway, I also wonder what is really the issue. It may or may not be just the label. depending on how the day_delta sum is calculated. Is it the sum of the archive_day sums? Is it the sum of archive's rain column, over 30 x 24h? 

When I manually calculate the sum of the last 6 days of the previous month, and add it to the current months sum, I am (currently) off by 0.1mm, which is exactly the amount that was measured after the current daytime on day 31 in the past, from now. So the the data source is "archive" table, but I don't know if the DST changed could influence the total in a corner case. This total is wrong if you interpret the value as "sum of the latest 30 calendar days", but may be correct, if interpreted as "sum of the latest 30 x 24h". But I don't know if it is really calculated that way.

[Karen K]

michael.k...@gmx.at schrieb am Donnerstag, 24. April 2025 um 11:41:39 UTC+2:

But anyway, I also wonder what is really the issue. It may or may not be just the label. depending on how the day_delta sum is calculated. Is it the sum of the archive_day sums? Is it the sum of archive's rain column, over 30 x 24h? 

May be, it is a matter of rounding. If the time period is 29 days and 23 hours, it is almost 30 days, but if you omit rounding it is 29 days.

Internally all timestamps are seconds since 1970-01-01 00:00:00 UTC. To get a timespan of days WeeWX uses the functions weeutil.archive{Day,Week,Month,Year}Span(),  which convert the value into a tuple of year, month, day, hour, minute, second local time, sets hour, minute, second to 0, applies the appropriate amount of days, and finally converts both ends back to seconds since 1970-01-01 00:00:00 UTC. If the timespan includes a daylight saving time switch, it is - in seconds - not whole days but an hour more or less.

[michael.k...@gmx.at]

Playing a little around, this is confusing me:

$span(hour_delta=720).length.day.format("%d")

=> 29 days. Okay...

$span(hour_delta=720).length.long_form

=> 719 hours, 0 minutes, 0 seconds. ???

So, for the hours, I can't think of a scenario, where I consider this as a correct result, and there isn't room for a rounding issue.

Nailing it down to the DST change, with the following lines

$span(hour_delta=632).length.long_form

$span(hour_delta=631).length.long_form

$span(hour_delta=630).length.long_form

$span(hour_delta=629).length.long_form

I get these results:

631 hours, 0 minutes, 0 seconds
630 hours, 0 minutes, 0 seconds
630 hours, 0 minutes, 0 seconds
629 hours, 0 minutes, 0 seconds

[gjr80]

I'm not sure what is confusing here. $span(hour_delta=720).length gives us a ValueHelper whose included ValueTuple covers a span of 720 * 3600 seconds. If the 720 hour period covers a DST start time the actual span will be 719 * 3600 seconds due to WeeWX being DST unaware. The .day converts the number of seconds to decimal days, assuming a DST start time is included the result is 29.958333 days (29 + 23/24ths). The .format("%d") simply formats this number as an integer giving the expected 29.

The .long_form applies slightly different formatting. Again assuming the hour_delta=720 covers a DST start time, and due to WeeWX DST naivety, the $span(hour_delta=720).length gives us a ValueHelper whose included ValueTuple covers a span of 719 * 3600 seconds. .long_form formats a span in seconds using a longer, human friendly format; if using the defaults an 'hours, minutes, seconds' format will be used. Since we have exactly 719 hours in the span the result is '719 hours, 0 minutes, 0 seconds'.

There are no rounding errors as such, just two different tags applying slightly different formatting. Perhaps there is something else that is confusing that I am not seeing.

Gary

[michael.k...@gmx.at]

I still don't get it. A system that isn't DST aware, shouldn't produce DST related differences. If it does, it fails to make sure, that it strips any DST related offsets for values that may be passed, before doing it's calculations.

[Karen K]

michael.k...@gmx.at schrieb am Samstag, 26. April 2025 um 13:01:58 UTC+2:

I still don't get it. A system that isn't DST aware, shouldn't produce DST related differences. If it does, it fails to make sure, that it strips any DST related offsets for values that may be passed, before doing it's calculations.

You may want to read about Python's datetime module. 

As I said before, time can be a scalar value of seconds or a tuple containing year, month, day, hour, minute, and second. WeeWX converts between them. If you want to understand timespans you have to understand when exactly which of those two is used and when conversion takes place. 

$span uses weeutil.weeutil.archiveSpanSpan to get the timespan. It receives a timestamp as a scalar value (seconds since 1970-01-01 00:00:00 UTC). First it converts that timestamp to a tuple in local time. Then it applies the deltas except the month delta using Python's datetime.timedelta class. See the Python documentation how it works in particular. For the month delta the method contains a special calculation. After all that calculating the tuple is converted back to a scalar value in seconds. The final timespan contains of both those scalar values in seconds since 1970-01-01 00:00:00 UTC. The length of the timespan is simply the difference of those values. It is the real amount of seconds. And this amount of seconds is really 3600 seconds less or more if a daylight savings time switch is within the timespan. To print the value the seconds are converted to hours, minutes, and seconds.

[michael.k...@gmx.at]

Thank you, now I understand. In the meantime this glitch disappeared, as expected, since the DST change is more than 30 days ago. No I've got some time to think about, how to deal with it :D