Re: [weewx-user] day is out of range for month

[Thomas Keffer]

This is probably a bug somewhere.

Did you modify the standard index.html.tmpl template? Can you identify what statement in the template is causing the error?

-tk

On Mon, Jul 31, 2017 at 1:32 AM, Pavel Fojt <goo...@fojt.cz> wrote:

after midnight (2017-07-30 / 2017-07-31):

Jul 31 10:30:14 debian1 weewx[143]: cheetahgenerator: Generate failed with exception '<type 'exceptions.ValueError'>'
Jul 31 10:30:14 debian1 weewx[143]: cheetahgenerator: **** Ignoring template /etc/weewx/skins/Standard/index.html.tmpl
Jul 31 10:30:14 debian1 weewx[143]: cheetahgenerator: **** Reason: day is out of range for month
Jul 31 10:30:14 debian1 weewx[143]: ****  Traceback (most recent call last):
Jul 31 10:30:14 debian1 weewx[143]: ****    File "/usr/share/weewx/weewx/cheetahgenerator.py", line 329, in generate
Jul 31 10:30:14 debian1 weewx[143]: ****      print >> _file, compiled_template
Jul 31 10:30:14 debian1 weewx[143]: ****    File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in __str__
Jul 31 10:30:14 debian1 weewx[143]: ****      rc = getattr(self, mainMethName)()
Jul 31 10:30:14 debian1 weewx[143]: ****    File "_etc_weewx_skins_Standard_index_html_tmpl.py", line 1663, in respond
Jul 31 10:30:14 debian1 weewx[143]: ****    File "_etc_weewx_skins_Standard_index_html_tmpl.py", line 707, in __errorCatcher92
Jul 31 10:30:14 debian1 weewx[143]: ****    File "<string>", line 1, in <module>
Jul 31 10:30:14 debian1 weewx[143]: ****    File "/usr/share/weewx/weewx/tags.py", line 101, in span
Jul 31 10:30:14 debian1 weewx[143]: ****      hour_delta=hour_delta, day_delta=day_delta, week_delta=week_delta, month_delta=month_delta, year_delta=year_delta),
Jul 31 10:30:14 debian1 weewx[143]: ****    File "/usr/share/weewx/weeutil/weeutil.py", line 532, in archiveSpanSpan
Jul 31 10:30:14 debian1 weewx[143]: ****      start_dt = time_dt.replace(year=year, month=month)
Jul 31 10:30:14 debian1 weewx[143]: ****  ValueError: day is out of range for month

weewx version v3.7.1

problem with 31days for July?

thanks

Pavel

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mph]

I am confirming this reported bug with $month_delta

My template GENERATING bug on Jul 31st:

#set $archive_data = [$day, $span($week_delta=1), $span($month_delta=1), $span($year_delta=1), $week, $month, $year]
...
#for $archive in $archive_data
  <td class="data new_row">$archive.outTemp.max.format(add_label=False)<br/>
    <span class="timestamp">$archive.outTemp.maxtime.format($dt_format[$archive_data.index($archive)])</span><br/>
    $archive.outTemp.min.format(add_label=False)<br/>
    <span class="timestamp">$archive.outTemp.mintime.format($dt_format[$archive_data.index($archive)])</span>
  </td>
#end for

My workarround SOLVING the issue - using day_delta only:

#set $archive_data = [$day, $span($day_delta=7), $span($day_delta=30), $span($day_delta=365), $week, $month, $year]

My log is almost the same as from Pavel Fojt below:

Jul 31 00:50:24 rpi-meteo weewx[25170]: cheetahgenerator: Generate failed with exception '<type 'exceptions.ValueError'>'
Jul 31 00:50:24 rpi-meteo weewx[25170]: cheetahgenerator: **** Ignoring template /etc/weewx/skins/Seasons/index.html.tmpl
Jul 31 00:50:24 rpi-meteo weewx[25170]: cheetahgenerator: **** Reason: day is out of range for month
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****  Traceback (most recent call last):
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****    File "/usr/share/weewx/weewx/cheetahgenerator.py", line 332, in generate
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****      fd.write(str(compiled_template))
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****    File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in __str__
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****      rc = getattr(self, mainMethName)()
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****    File "_etc_weewx_skins_Seasons_index_html_tmpl.py", line 218, in respond
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****    File "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1615, in _handleCheetahInclude
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****      self._CHEETAH__cheetahIncludes[_includeID].respond(trans)
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****    File "_etc_weewx_skins_Seasons_hilo_inc.py", line 94, in respond
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****    File "/usr/share/weewx/weewx/tags.py", line 101, in span
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****      hour_delta=hour_delta, day_delta=day_delta, week_delta=week_delta, month_delta=month_delta, year_delta=year_delta),
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****    File "/usr/share/weewx/weeutil/weeutil.py", line 475, in archiveSpanSpan
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****      start_dt = time_dt.replace(year=year, month=month)
Jul 31 00:50:24 rpi-meteo weewx[25170]: ****  ValueError: day is out of range for month

Thank you
Pavel

Dne úterý 1. srpna 2017 15:18:35 UTC+2 Thomas Keffer napsal(a):

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

[Thomas Keffer]

Thanks, mph. This helps! It seems the problem is on the last day of a long month that follows a short month.

I've created issue #436 to track.

-tk

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/fe6603a7-00f7-4d6e-8537-ccebca757891%40googlegroups.com.

[Thomas Keffer]

Finally got around to looking at this and now I'm not so sure it is a bug.

Let me ask you a question: given the date you were using, 31 July, what was your expectation for the date a month earlier? Not 31 June; there is no such day. 

One could say it should be the last day in June, that is, 30 June. That might make sense, but then it leads to some strange corner cases:

What is 30 March minus one month? By this solution, it should be 28 Feb.

So then what is 29 March minus one month? Also 28 Feb? And so would 28 March minus a month. So, "one month earlier" for three days in a row leads to the same date?

Any ideas?

-tk

[Andrew Milner]

I am inclined to agree with you Tom in that this isn't a bug.  The 'workaround' using a 30 day month and 365 day year is, I feel, the only way to logically achieve a consistent outcome.

On Thursday, 19 September 2019 01:26:47 UTC+3, Thomas Keffer wrote:

Finally got around to looking at this and now I'm not so sure it is a bug.

Let me ask you a question: given the date you were using, 31 July, what was your expectation for the date a month earlier? Not 31 June; there is no such day. 

One could say it should be the last day in June, that is, 30 June. That might make sense, but then it leads to some strange corner cases:

What is 30 March minus one month? By this solution, it should be 28 Feb.

So then what is 29 March minus one month? Also 28 Feb? And so would 28 March minus a month. So, "one month earlier" for three days in a row leads to the same date?

Any ideas?

-tk

On Tue, Jul 30, 2019 at 5:17 PM Thomas Keffer <tke...@gmail.com> wrote:

Thanks, mph. This helps! It seems the problem is on the last day of a long month that follows a short month.

I've created issue #436 to track.

-tk

To unsubscribe from this group and stop receiving emails from it, send an email to weewx...@googlegroups.com.

[gjr80]

I had a similar issue with WeeWX-WD some years back, the Saratoga templates needed to display some observation (temp or rain - can't remember) for the same time past month. To be honest I can't remember what I had it return for 'problem' dates, it certainly was not None or some other undefined value.

That aside, whether you call it a bug or not I don't think we should have a tag that when you give it an allowed value/parameter it aborts the template. Perhaps return None so the template is still processed and then at least the user has some value to hang his hat on.

Gary

[Graham Eddy]

don’t know enough about specifying timespans within weewx but you can do things like

  sqlite3> select datetime(dateTime, 'unixepoch’, ’localtime’, ’-1 months’) from archive;

and

  bash$ date -v-1m

____________

Graham Eddy

--
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/6b4c212c-2225-4771-8bdd-92631109aff7%40googlegroups.com.

[Andrew Milner]

what do sqlite3 and bash return on say 29, 30 and 31 march when one tries to subtract 1 month?

On Thursday, 19 September 2019 10:51:04 UTC+3, Graham Eddy wrote:

don’t know enough about specifying timespans within weewx but you can do things like

  sqlite3> select datetime(dateTime, 'unixepoch’, ’localtime’, ’-1 months’) from archive;

and

  bash$ date -v-1m

____________

Graham Eddy

On 19 Sep 2019, at 4:37 pm, gjr80 <gjrod...@gmail.com> wrote:

I had a similar issue with WeeWX-WD some years back, the Saratoga templates needed to display some observation (temp or rain - can't remember) for the same time past month. To be honest I can't remember what I had it return for 'problem' dates, it certainly was not None or some other undefined value.

That aside, whether you call it a bug or not I don't think we should have a tag that when you give it an allowed value/parameter it aborts the template. Perhaps return None so the template is still processed and then at least the user has some value to hang his hat on.

Gary

--
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...@googlegroups.com.

[Graham Eddy]

sqlite> select datetime('2019-03-15 12:00:00', '-1 months');

2019-02-15 12:00:00

sqlite> select datetime('2019-03-28 12:00:00', '-1 months');

2019-02-28 12:00:00

sqlite> select datetime('2019-03-29 12:00:00', '-1 months');

2019-03-01 12:00:00

sqlite> select datetime('2019-03-30 12:00:00', '-1 months');

2019-03-02 12:00:00

sqlite> select datetime('2019-03-31 12:00:00', '-1 months');

2019-03-03 12:00:00

sqlite> select datetime('2019-04-01 12:00:00', '-1 months');

2019-03-01 12:00:00

sqlite> select datetime('2019-03-04 12:00:00', '-1 months');

2019-02-04 12:00:00

bash$ date -j '0315120019'

Fri 15 Mar 2019 12:00:00 AEDT

bash$ date -j -v-1m '0315120019'

Fri 15 Feb 2019 12:00:00 AEDT

bash$ date -j -v-1m '0329120019'

Thu 28 Feb 2019 12:00:00 AEDT

bash$ date -j -v-1m '0330120019'

Thu 28 Feb 2019 12:00:00 AEDT

bash$ date -j -v-1m '0331120019'

Thu 28 Feb 2019 12:00:00 AEDT

____________

Graham Eddy

[Greg from Oz]

date --date="2019/03/29 -1 month"

Fri  1 Mar 00:00:00 AEDT 2019

date --date="2019/03/30 -1 month"

Sat  2 Mar 00:00:00 AEDT 2019

 date --date="2019/03/31 -1 month"

Sun  3 Mar 00:00:00 AEDT 2019

[Andrew Milner]

Well personally I would say that it is an error to say 31 mar - 1 month = 3 mar, although I appreciate the logic behind the outcome.  I guess it all depends on how 'month' is defined!  if 'month' is defined as length of ciurrent month the date - month should return date - number of days in current month

and so 31 mar would return 28 feb

30 mar would return 27 feb

29 mar would return 26 feb

i do not think it is correct to advance forwards into march as date appears to do.

[Thomas Keffer]

On Wed, Sep 18, 2019 at 11:37 PM gjr80 <gjrod...@gmail.com> wrote:

That aside, whether you call it a bug or not I don't think we should have a tag that when you give it an allowed value/parameter it aborts the template. 

We don't. The tag that caused the error was user-supplied.

From Graham's experiments, it looks like sqlite and bash simply subtract four weeks. The span tag can already do that, so if that's what the user wants, s/he can just specify it.

As for Python, it doesn't even offer month arithmetic (at least, through class datetime.timedelta), probably for the reasons we have discovered. I'm thinking we should do the same.

-tk

 

[mph]

Hi all,

the primary requirement is: „Do not generate errors on month_delta mathematics“

The implementation and thus resulting date is not so important, I think.

So if we will implement any error-free logic, then everything will be ok.

 

In my opinion, if the user has date say Mar 10th, or 03/10 and wants to subtract one month, it just wants to do MM=03-1 -> 02/10. If the formula generates invalid date (03/31 -> 02/31) then we should offer a valid date, e.g. 02/28. Nothing more special.
For general use the implementation of any existing logic (bash) should be acceptable.

Thank you

Pavel

Dne čtvrtek 19. září 2019 15:00:20 UTC+2 Thomas Keffer napsal(a):

[Thomas Keffer]

I guess I'm queasy at the thought of a solution that simply does not raise an error. It should obey some basic laws of math. For example, subtracting a month, then adding it back on should yield the same date. This solution would not.

I'm in favor of eliminating month arithmetic. It doesn't add anything.

Alternatively, we could leave it in, but require the user to catch any exceptions, then make up his/her mind what the semantics should be.

-tk

--

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/36ad9d07-b295-4733-b0b2-44c9437133cd%40googlegroups.com.

[Andrew Milner]

...... or compromise, and define 'month' = 30 days in weewxese perhaps.

On Thursday, 19 September 2019 17:39:47 UTC+3, Thomas Keffer wrote:

I guess I'm queasy at the thought of a solution that simply does not raise an error. It should obey some basic laws of math. For example, subtracting a month, then adding it back on should yield the same date. This solution would not.

I'm in favor of eliminating month arithmetic. It doesn't add anything.

Alternatively, we could leave it in, but require the user to catch any exceptions, then make up his/her mind what the semantics should be.

-tk

On Thu, Sep 19, 2019 at 6:25 AM mph <mph....@gmail.com> wrote:

Hi all,

the primary requirement is: „Do not generate errors on month_delta mathematics“

The implementation and thus resulting date is not so important, I think.

So if we will implement any error-free logic, then everything will be ok.

 

In my opinion, if the user has date say Mar 10th, or 03/10 and wants to subtract one month, it just wants to do MM=03-1 -> 02/10. If the formula generates invalid date (03/31 -> 02/31) then we should offer a valid date, e.g. 02/28. Nothing more special.
For general use the implementation of any existing logic (bash) should be acceptable.

Thank you

Pavel

Dne čtvrtek 19. září 2019 15:00:20 UTC+2 Thomas Keffer napsal(a):

On Wed, Sep 18, 2019 at 11:37 PM gjr80 <gjrod...@gmail.com> wrote:

That aside, whether you call it a bug or not I don't think we should have a tag that when you give it an allowed value/parameter it aborts the template. 

We don't. The tag that caused the error was user-supplied.

From Graham's experiments, it looks like sqlite and bash simply subtract four weeks. The span tag can already do that, so if that's what the user wants, s/he can just specify it.

As for Python, it doesn't even offer month arithmetic (at least, through class datetime.timedelta), probably for the reasons we have discovered. I'm thinking we should do the same.

-tk

 

--
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...@googlegroups.com.

[p q]

Might as well set Pi=3 while you're at it

(sarcasm)

Seriously. Please don't set month=30 days. It won't end well.

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/9df7a851-5ec6-43c3-8231-4d6f06364a58%40googlegroups.com.

--

Peter Quinn
(415)794-2264

[vince]

On Thursday, September 19, 2019 at 7:39:47 AM UTC-7, Thomas Keffer wrote:

I'm in favor of eliminating month arithmetic. It doesn't add anything.

Wow there are a lot of edge cases. Graham's experiment makes my head spin.

Perl does it this way - https://metacpan.org/pod/DateTime#$dt-%3Esubtract_datetime(-$datetime-)

I particularly liked the "Note that this duration is not an absolute measure of the amount of time between the two datetimes, because the length of a month varies, as well as due to the presence of leap seconds."

There doesn't seem to be a great answer on this one that doesn't get really complicated.

[gjr80]

On Thursday, 19 September 2019 23:00:20 UTC+10, Thomas Keffer wrote:

On Wed, Sep 18, 2019 at 11:37 PM gjr80 <gjrod...@gmail.com> wrote:

That aside, whether you call it a bug or not I don't think we should have a tag that when you give it an allowed value/parameter it aborts the template. 

We don't. The tag that caused the error was user-supplied.

Technically you are right, but for my thinking the real cause is the underlying WeeWX native $span($month_delta=1).

 

As for Python, it doesn't even offer month arithmetic (at least, through class datetime.timedelta), probably for the reasons we have discovered. I'm thinking we should do the same.

I tend to agree, I appreciate that leaving an error for the user to trap and handle is a common way to handle such situations, but I still have a bit of a problem that a native WeeWX tag with quite acceptable parameters causes a template to fail. Providing $span with deltas of weeks, days etc down to seconds gives the user the flexibility to define their 'month' how they like (4 weeks, 30 or 31 days)

At the end of the day if we were prepared to let the user catch an error from a tag in a template using some inline python, then equally we can let them implement a bit of inline python in their template to feed $span with whatever 'month ago' value they want.

And of course all the above applies equally as well to $year_delta.

Gary

[gjr80]

On Friday, 20 September 2019 02:07:37 UTC+10, p q wrote:

Might as well set Pi=3 while you're at it

(sarcasm)

Seriously. Please don't set month=30 days. It won't end well.

Well I guess we need to standby for complaints about the 'month' plots...

Gary

[Thomas Keffer]

Damn. I just realized we have the same problem with years. Quick, what is 2016-02-29 minus one year?

[gjr80]

Just get rid of it! Problem solved :)

Gary

[Andrew Milner]

I've finally come around to return None so that the user can take trap the situation and take remedial actions if necessary but the template will at least complete without giving an error.

Either that or for weewx to define what is meant by week, month and year in terms of days and to use those definitions.  One could expand the definitions by also having calendarmonth and calendaryear if one wished to really complicate things.

I think I've now had more than my pennyworth of opinions on this topic!!

[Graham Eddy]

"When I use a word," Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean—neither more nor less."

just be consistent, whether it be ‘right’ or ‘wrong’ by "common sense"

____________

Graham Eddy

--
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/7086c963-6b87-48c1-8ad8-04be4ecb8e97%40googlegroups.com.

[Graham Eddy]

sqlite> select datetime('2016-02-29 12:00:00', '-1 years');

2015-03-01 12:00:00

bash$ date -j '0229120016'

Mon 29 Feb 2016 12:00:00 AEDT

bash$ date -j -v-1y '0229120016'

Sun  1 Mar 2015 12:00:00 AEDT

____________

Graham Eddy

On 20 Sep 2019, at 10:30 am, Thomas Keffer <tke...@gmail.com> wrote:

Damn. I just realized we have the same problem with years. Quick, what is 2016-02-29 minus one year?

--
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/CAPq0zEByjsdoPLNX5ASoKOkrMSLbH1pmeVJrZOTunT1mb1_Z%3Dw%40mail.gmail.com.

[mph]

I am not sure that doing a precise math with the months or years is neccessary. Do you have a use case of that (x = aDate - $month_delta + $month_delta)?

If we imagine year as a line of days aligned to 31 days per month, then we will have line with days and gaps.
The $month_delta (and $year_delta too) should just subtract / add length of the month/year in days, and when it will fall in a gap, then we should continue over the line to the nearest valid date.

Feb 2016                 Mar 2016                    Apr 2016                    May 2016
01-02-...-27-28-29-NA-NA-01-02-03-...-27-28-29-30-31-01-02-03-...-27-28-29-30-NA-01-02-03-...
Subtraction        |                                                          |
                   Mar 30 - $month_delta=1                                    May 31 - $month_delta=1
                  <-                                                         <-
                      |
                      Mar 31 - $month_delta=1
                  <- <-

Addition           |                                                          |
                   Jan 30 + $month_delta=1                                    Mar 31 + $month_delta=1
                    -> ->                                                      ->
                      |
                      Jan 31 + $month_delta=1
                       ->

Similarly for $year_delta.

IMHO This is the way how majority of people generally think about it and weewx should work this way.
It is perfectly ok to make a notice in the documentation and leave users to consider using it or not for their purpose, even with "not so precise reversible mathematics".


Pavel


Dne čtvrtek 19. září 2019 16:39:47 UTC+2 Thomas Keffer napsal(a):

I guess I'm queasy at the thought of a solution that simply does not raise an error. It should obey some basic laws of math. For example, subtracting a month, then adding it back on should yield the same date. This solution would not.

I'm in favor of eliminating month arithmetic. It doesn't add anything.

Alternatively, we could leave it in, but require the user to catch any exceptions, then make up his/her mind what the semantics should be.

-tk

On Thu, Sep 19, 2019 at 6:25 AM mph <mph....@gmail.com> wrote:

Hi all,

the primary requirement is: „Do not generate errors on month_delta mathematics“

The implementation and thus resulting date is not so important, I think.

So if we will implement any error-free logic, then everything will be ok.

 

In my opinion, if the user has date say Mar 10th, or 03/10 and wants to subtract one month, it just wants to do MM=03-1 -> 02/10. If the formula generates invalid date (03/31 -> 02/31) then we should offer a valid date, e.g. 02/28. Nothing more special.
For general use the implementation of any existing logic (bash) should be acceptable.

Thank you

Pavel

Dne čtvrtek 19. září 2019 15:00:20 UTC+2 Thomas Keffer napsal(a):

On Wed, Sep 18, 2019 at 11:37 PM gjr80 <gjrod...@gmail.com> wrote:

That aside, whether you call it a bug or not I don't think we should have a tag that when you give it an allowed value/parameter it aborts the template. 

We don't. The tag that caused the error was user-supplied.

From Graham's experiments, it looks like sqlite and bash simply subtract four weeks. The span tag can already do that, so if that's what the user wants, s/he can just specify it.

As for Python, it doesn't even offer month arithmetic (at least, through class datetime.timedelta), probably for the reasons we have discovered. I'm thinking we should do the same.

-tk

 

--
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...@googlegroups.com.

[Greg Troxel]

Thomas Keffer <tke...@gmail.com> writes:

> Damn. I just realized we have the same problem with years. Quick, what is
> 2016-02-29 minus one year?

One good answer is 2015-03-01, and another is 2015-02-28. I prefer 3/1.



I would suggest stepping back and asking why we do these calculations,
hat answers are sensible/useful, and what properties the calculations
need.

I saw a notion that this basic math property should hold

one_month_after( one_month_before(X) ) = X

but I'm not sure that's a requirement. The math nerd in me can
certainly see the appeal, but also that our calendar doesn't work that way.

If someone wants to make a graph over "a month ago to now", or ask "what
was the low temperature over the last month" on some particular day,
that's a reasonable question. I think it's just as reasonable a
question to ask as "over the last 30 days" or "over the last 29.57 days".

I think it's reasonable to take Y-M-D and subtract one month, and then
move forward if that's invalid, so

2019-01-15 => 2018-12-15
2019-03-28 => 2019-02-28
2019-03-29 => 2019-03-01
2019-03-30 => 2019-03-01
2019-03-31 => 2019-03-01
2019-04-01 => 2019-03-01

and so be it. Yes, the time interval between these pairs varies - but
our months do have different lengths. Humans don't expect to be able to
say "what was the date a month ago" and then "on that date, what's a
month in the future" and get the same date. Humans also don't expect a
fixed answer to "between a month ago and now, how many days are there".

If people want to ask the question "30 days ago", that's fine, and they
should be able to do that instead.

[Andrew Milner]

what you say is correct if dealing with one month ago - but lets now imagine it is say 31 may and we wish to go back 2, 3 or 4 months - where should we end up??

[Greg Troxel]

Andrew Milner <andrew.s...@gmail.com> writes:

> what you say is correct if dealing with one month ago - but lets now
> imagine it is say 31 may and we wish to go back 2, 3 or 4 months - where
> should we end up??

My take is that if someone asks a fuzzy question and gets an answer that
is in the set of arguably reasonable answers, it's ok. I think that's
far better than throwing an exception.

For going back N months from y/m/d:

m -= N

while m < 1, then {y -= 1; m += 12 }

if ( d is not valid for m )
move to the 1st of m+1

and call that good enough.

[Andrew Milner]

mmmm

think I agree except for preferring to going to last day of m rather than first day of m+1 because otherwise you can end up in the situation where month - 1 leaves you in the same month which does not seem right.

otherwise I think your logic is spot-on, and I was confusing myself by considering the lengths of the months inbetween rather than just considering the final landing month.

On Friday, 20 September 2019 16:34:31 UTC+3, Greg Troxel wrote:

[Greg Troxel]

Andrew Milner <andrew.s...@gmail.com> writes:

> mmmm
> think I agree except for preferring to going to last day of m rather than
> first day of m+1 because otherwise you can end up in the situation where
> month - 1 leaves you in the same month which does not seem right.

That's a good point about preferring a different calendar month. Your
strategy also leads to reasonable day-deltas, 3/31 leads to 2/28 which
is.... 31 days ago. So I think we'd end up with 28-31 days between any
pair "today" and "a month ago from today ", which is a good property.

You have convinced me to change to move earlier to valid day. That's
pretty simple, too, just set to last day of month if calculated is > last.

> otherwise I think your logic is spot-on, and I was confusing myself by
> considering the lengths of the months inbetween rather than just
> considering the final landing month.

I was trying to think "If I ask some random person on the street: what
date is today? what date was 4 months ago?" what answer would I get and
then trying to mechanize that.

[Thomas Keffer]

Well, I made an "executive decision" and decided to deprecate month_delta and year_delta. One can always add and subtract 30 days, or 365 days.

--
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/rmisgor83s9.fsf%40s1.lexort.com.

[p q]

So I show "On this day" for the previous years on my site. I'll need to recode this when I upgrade? Seems like a step backwards for the edge case where it doesn't work one day out of 1461. But, I'll deal with it when I upgrade someday.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEDrEAtiz_i3%3DWi-Nrn%2BYHpprHT89R0zmv4SUHbiOQmQ_g%40mail.gmail.com.

--

Peter Quinn
(415)794-2264

[Thomas Keffer]

The parameter "year_delta" is still there, just deprecated. No plans to take it out anytime soon. Just expect a Python exception to occur once every four years!

-tk

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAA1SM21MixgytdiQmHR-c6q4af9z_29t793RvvJGXc8dFZ8rJw%40mail.gmail.com.