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.
gjr80 schrieb am Samstag, 26. April 2025 um 07:32:58 UTC+2:
> 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
> On Friday, 25 April 2025 at 19:21:49 UTC+12 michael.k...@gmx.at wrote:
>
>> 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
>>
>>
>> Karen K schrieb am Donnerstag, 24. April 2025 um 21:07:02 UTC+2:
>>
>>> 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.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to weewx-user+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/weewx-user/9fe548c6-3abb-4d02-92ef-057a6e26a18cn%40googlegroups.com.
