Greg Troxel <g...@lexort.com> 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 weewx-development+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/rmipndlv950.fsf%40s1.lexort.com.
