Why are the Weather intervals (week, month, year) all off by one day?

[Marcus Zurhorst]

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

[Tom Keffer]

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. 

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

[Karen K]

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.

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

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.

[Tom Keffer]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/4cc4e8cd-9a0f-4987-a9f5-ccf824809913n%40googlegroups.com.

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

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]

My comment was in response to Karen's comment.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/9f3289b9-29d9-468c-95a5-6cf666bee7d2n%40googlegroups.com.

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

Ah! Ok! Nevermind. I probably never really get warm with google groups... :^)

[David Bätge]

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 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 :)