Try running this little program:
import os
import time
import datetime
os.environ['TZ'] = 'America/New_York'
time.tzset()
dt = datetime.datetime(2020,3,8,1)
tt = dt.timetuple()
print("Starting datetime is %s" % dt)
print("Represented as a time tuple, this is %s" % tt)
delta = datetime.timedelta(seconds=3600)
dt1 = dt + delta
print("After adding an hour, the resultant datetime is %s" % dt1)
tt1 = dt1.timetuple()
print("Represented as a timetuple this is %s" % tt1)
ts = time.mktime(tt1)
print("In unixtime: %f" % ts)
print("As time.ctime(), this is %s" % time.ctime(ts))
I get:
Starting datetime is 2020-03-08 01:00:00
Represented as a time tuple, this is time.struct_time(tm_year=2020,
tm_mon=3, tm_mday=8, tm_hour=1, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=68,
tm_isdst=-1)
After adding an hour, the resultant datetime is 2020-03-08 02:00:00
Represented as a timetuple this is time.struct_time(tm_year=2020, tm_mon=3,
tm_mday=8, tm_hour=2, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=68,
tm_isdst=-1)
In unixtime: 1583650800.000000
As time.ctime(), this is Sun Mar 8 03:00:00 2020
On Mon, Mar 9, 2020 at 8:30 AM Greg Troxel <[email protected]> wrote:
> Greg Troxel <[email protected]> writes:
>
> (Earlier, on weewx-user, I posted that I was seeing a backtrace from
> v4beta (recent master). I'm following up here now that I've read the
> code and have something perhaps useful to say.)
>
> > Traceback (most recent call last):
> > File "/usr/weewx/bin/weewx/reportengine.py", line 197, in run
> > obj.start()
> > File "/usr/weewx/bin/weewx/reportengine.py", line 280, in start
> > self.run()
> > File "/usr/weewx/bin/weewx/imagegenerator.py", line 41, in run
> > self.genImages(self.gen_ts)
> > File "/usr/weewx/bin/weewx/imagegenerator.py", line 180, in genImages
> > aggregate_interval=aggregate_interval)
> > File "/usr/weewx/bin/weewx/xtypes.py", line 86, in get_series
> > aggregate_interval)
> > File "/usr/weewx/bin/weewx/xtypes.py", line 138, in get_series
> > for stamp in weeutil.weeutil.intervalgen(startstamp, stopstamp,
> aggregate_interval):
> > File "/usr/weewx/bin/weeutil/weeutil.py", line 339, in intervalgen
> > stamp2 = int(time.mktime(dt2.timetuple()))
> > OverflowError: mktime argument out of range
>
> I am using python 2.7, NetBSD 8 on earmv7hf-el. weewx 3.x has run for
> over 2 years with essentially no problems.
>
> Ihave added printfs to weeutil.py, in intervalgen. The crash happens
> during the loop in else block. The last dt2 printout is
>
> dt2 2020-03-08 02:00:00
>
> which is a time that does not exist (here in EST5EDT). So apparently
> the python time doing the addition in the datetime object is not going
> back to timeval each time.
>
> I am using the older skin that was standard before the Seasons skin
> became normal.
>
> Is anyone else seeing this? You can tell you are having this problem
> two ways:
> traceback in log during html report generation
> graphs on week/month/year page are stale
>
>
>
> I looked at python datetime docs:
> https://docs.python.org/3/library/datetime.html
> https://docs.python.org/2/library/datetime.html
>
> There is a notion of "aware" vs "naive" datetime objects, and as I read
> it the code is creating naive objects, which don't have an associated
> timezone. So adding 3600s to 2020-03-08T01:00 leads to 02:00, even
> though I think that time doesn't exist and the right answer is 03:00.
>
> time.mktime() says it will raise an error if the time cannot be
> represented:
> https://docs.python.org/2/library/time.html
>
>
> I think to fix, we need a try: block that just does mktime on dt2 and
> discards the result, with an catch block that does continue, so we
> increment dt2 again. Or, to pass the local tz in the constructor,
> perhaps.
>
> I suppose it is possible that the underlying mktime library function on
> NetBSD is stricter than on Other Systems. The man page says:
>
> The function returns the specified calendar time; if the
> calendar
> time cannot be represented, it returns (time_t)-1. This can
> happen
> either because the resulting conversion would not fit in a
> time_t
> variable, or because the time specified happens to be in the
> daylight savings gap and tm_isdst was set to -1. Other mktime()
> implementations do not return an error in the second case and
> return the appropriate time offset after the daylight savings
> gap.
> There is code to mimick this behavior, but it is not enabled by
> default.
>
> and also makes a claim of conforming to C89.
>
> I have previously observed test failures in bup (a backup program using
> git data storage, written in python), and reproduced problems in git. I
> didn't ever chase that down, but I am now suspecting the same underlying
> cause, namely invocations of mktime which are incorrect according to
> standards, but happen to work anyway on Linux. (That is of course
> guess, not a substantiated conclusion.)
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-development" 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-development/rmipndlv950.fsf%40s1.lexort.com
> .
>
--
You received this message because you are subscribed to the Google Groups
"weewx-development" 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-development/CAPq0zEBvtbPE2ptg1zm-O1aNHmESD7_OS0Q4TwfpXS0OV7_8fA%40mail.gmail.com.
