Tom explained the reason, I want to add some important consideration: you 
need to distinguish between an Instant (e.g.  1-Feb-2010 00:0000.123456789 ) 
and a (Local!) calendar date. If you want a report "Average Temperature in 
March 2022" for your station, it needs to be based on all the values 
specified by 2022-03-01 up until 2022-03-31 your local date, as defined by 
the instants  2022-03-01 00:00 until 2022-04-01 00:00, your local time zone 
at each of these instants, even if there is a daylight savings time 
transition in between, which makes March one hour shorter than May.

Distinguishing between Dates and Instants is often done, without 
recognizing it: "We meet at noon at the train station" will probably make 
you meet your friend. On the other hand, you and your friend can have 
different birthdays, even if you were born in the very same instant, but in 
different time zones.

Karen K schrieb am Dienstag, 28. Februar 2023 um 18:53:10 UTC+1:

> May be it worth mentioning the background that the archive interval is 
> open at the left end (start time) and closed at the right end (end time). 
> That is not uncommon. It is a widely used design. That is because it is the 
> only way to combine values that summarize the archive interval with actual 
> readings. Unfortunately the day is counted the other way round: It starts 
> at 00:00 and ends right before 00:00 the next day.
>
> Tom Keffer schrieb am Dienstag, 28. Februar 2023 um 18:02:30 UTC+1:
>
>> I assume you are referring to the tags $month.start and $month.end, the 
>> start and stop of the interval $month. See 
>> http://www.weewx.com/docs/customizing.htm#Start,_end,_and_dateTime
>>
>> Using the example from the Customizing Guide, if $month.end returned 
>> 31-Jan-2010, what time should it be? It can't be 00:00: we would be missing 
>> the whole day 31-Jan-2010. It also can't be 24:00: no such time exists. 
>>
>> So, it must be 1-Feb-2010 at midnight. The month runs right up to the 
>> instant the clock turns over into February.
>>
>> Now I recognize that when one is running a report that works in units of 
>> days, not instants of time, you might want to represent the end of the 
>> month as being 31-Jan-2010 (no time) and not 1-Feb-2010 00:00. 
>>
>> Thinking out loud here, we could create tags such as:
>>
>> $week.last_day
>> $month.last_day
>> $year.last_day
>>
>> but I'm not sure what they would return. While the tag $month.end 
>> returns a ValueHelper that holds a unix epoch time internally, that's 
>> not going to work for $month.last_day, because it will print 31-Jan-2010 
>> 00:00 --- not what we want. The user would have to always remember to 
>> custom format it to show only days --- no time. Something like 
>> $month.last_day.format("%d-%b-%Y"). That feels wrong.
>>
>> Alternatively, $month.last_day could return a Julian Day or a Python 
>> datetime.date object. I'd have to think about it.
>>
>> If you're really stuck, you can always custom format the end of the month 
>> like this:
>>
>> #from time import strftime, localtime
>> <p>Month ends at $strftime("%d-%b-%Y", $localtime($month.end.raw - 1
>> ))</p>
>>
>>
>> Note the "- 1". That shoves the time into the previous day. The results 
>> will be 31-Jan-2010. 
>>
>>
>>
>>
>> On Tue, Feb 28, 2023 at 5:32 AM Marcus Zurhorst <[email protected]> 
>> wrote:
>>
>>> Hi all.
>>>
>>> *I am wondering why the website tells me that the intervall for the 
>>> current months spans "01.02.2023 - 01.03.2023"? -- Same for year, which 
>>> goes to Jan 1, 2024 actually.*
>>>
>>>
>>> *Whilst being a minor glitch, I do not understand this design decision 
>>> at all since it is uncommon. Can somebody explain which this is done this 
>>> way? Plus, is this even theme-related, or would that be a discussion for 
>>> the weewx project itself?*
>>>
>>> I have initially raised this question on Github [1 
>>> <https://github.com/Daveiano/weewx-wdc/discussions/115>] with regard to 
>>> the weewx-wdc theme.
>>> Daveiano first thought that this would be specific to his theme. But 
>>> when looking into this, he actually found out that this would be related to 
>>> weewx itself.
>>>
>>> Can somebody please elaborate why this is designed like this?
>>>
>>> Thanks a lot.
>>>
>>> Best regards,
>>>   Marcus
>>>
>>>
>>> [1]  https://github.com/Daveiano/weewx-wdc/discussions/115
>>>
>>> -- 
>>> 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 [email protected].
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/67d68675-8be6-42c9-9602-098bfe908d4en%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/67d68675-8be6-42c9-9602-098bfe908d4en%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/927c34c6-cc0f-4fd6-a813-0ba0533e2cd5n%40googlegroups.com.

Reply via email to