*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*


Yes, that's exactly how this question was born. The weewx-wdc skin 
generates a page for each period (week, month, year), for example, the month's 
page <https://www.weewx-hbt.de/month.html> has a heading like:

Monthly Weather Conditions
03/01/23 - 04/01/23

03/01/23 - 04/01/23 is the output from $month.start - $month.end.

*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. *

That's a good solution to the actual problem, I was not sure about the 
internals of period handling but the explanations of Tom and Karen are 
making perfect sense, thank you. After understanding this, I think I will 
implement the small change :)
michael.k...@gmx.at schrieb am Dienstag, 28. Februar 2023 um 21:29:45 UTC+1:

> Ah! Ok! Nevermind. I probably never really get warm with google groups... 
> :^)
>
> Tom Keffer schrieb am Dienstag, 28. Februar 2023 um 20:43:57 UTC+1:
>
>> My comment was in response to Karen's comment.
>>
>> On Tue, Feb 28, 2023 at 10:58 AM michael.k...@gmx.at <michael.k...@gmx.at> 
>> wrote:
>>
>>> Yes, I agree, but I am thinking a little bit out of the standard weewx 
>>> box. A calculated average month observation, computed by weewx, using the 
>>> local timezone, uploading to a static website will be lead to a common user 
>>> experience, regardless where it is viewed from. On the other hand, when you 
>>> compare https://www.kainzbauer.net/weather/Rif/en/ with 
>>> https://www.kainzbauer.net/weather/Rif/en/day.html you will probably 
>>> recognize that the live charts are in your browser time zone, the static 
>>> images in the stations local time zone. eCharts doesn't support setting a 
>>> time zone independently from the browsers (systems?) time zone. If I would 
>>> compute monthly average values in the front end, there would be a 
>>> difference, depending on the time zone settings of the viewer's system.
>>>
>>> Tom Keffer schrieb am Dienstag, 28. Februar 2023 um 19:43:34 UTC+1:
>>>
>>>> If you regard a day as ending precisely at midnight, the convention is 
>>>> the same for both archive intervals and for a day: exclusive on the left, 
>>>> inclusive on the right. 
>>>>
>>>> A five-minute archive interval timestamped 11:35 includes all data from 
>>>> just after 11:30 to precisely 11:35. In a similar manner, a day 
>>>> timestamped 
>>>> 1-Feb-2010 includes all data from just after 31-Jan 00:00 to precisely 
>>>> 1-Feb 00:00.
>>>>
>>>> On Tue, Feb 28, 2023 at 9:53 AM Karen K <kk44...@gmail.com> wrote:
>>>>
>>>>> 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 <marcusz...@gmail.com> 
>>>>>> 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 weewx-user+...@googlegroups.com.
>>>>>>> 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 weewx-user+...@googlegroups.com.
>>>>>
>>>> To view this discussion on the web visit 
>>>>> https://groups.google.com/d/msgid/weewx-user/4cc4e8cd-9a0f-4987-a9f5-ccf824809913n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/weewx-user/4cc4e8cd-9a0f-4987-a9f5-ccf824809913n%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 weewx-user+...@googlegroups.com.
>>>
>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/weewx-user/9f3289b9-29d9-468c-95a5-6cf666bee7d2n%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/weewx-user/9f3289b9-29d9-468c-95a5-6cf666bee7d2n%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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/3c795f40-3d48-48ee-a5b4-0269f36bc0c0n%40googlegroups.com.

Reply via email to