Thomas Keffer <tkef...@gmail.com> writes: > OK, so we've isolated the issue to a problem with how NetBSD implements > time.mktime().
I don't think it's a problem in the implementation, just not matching the weewx code's beyond-standards expectation. As I understand it, an error return for times that do not exist in the local timezone is the standard approach for mktime, and guessing what it might mean, while obviously useful, is an extension. (If it is a NetBSD bug, I'll file a ticket and see about fixing it; we are as a group pretty hard-core about standards compliance.) I just looked at the sources, and there is a default-off option NO_ERROR_IN_DST_GAP. Reading the logs, it seems people think the error behavior in the gap is correct. But even if is a bug, it would be nice to avoid it. > I suppose we could trap the exception in intervalgen() and, instead, return > the simple arithmetic result of adding increment. Something like: > > delta = datetime.timedelta(seconds=interval) > last_stamp1 = 0 > while dt1 < stop_dt: > dt2 = min(dt1 + delta, stop_dt) > stamp1 = int(time.mktime(dt1.timetuple())) > try: > stamp2 = int(time.mktime(dt2.timetuple())) > except OverflowError: > stamp2 = stamp1 + interval > if stamp2 > stamp1 > last_stamp1: > yield TimeSpan(stamp1, stamp2) > last_stamp1 = stamp1 > dt1 = dt2 We could, and I think that would work fine. But, taking a step back, I think the code is ending up running in a situation where it isn't helpful, and in the case mktime doens't raise an exception, returning not what's expected. First, I get it that with dt1 being some date and 0000, and interval 24h, we want the posix time_t values corresponding to local midnight, even if a day is 23h or 25h. And simlarly when interval is 3h, 6h, or 12h. (I have seen the graphs that result in plotting programs that aren't aware of this, and they are difficult to read and ugly!) But when interval is 1h, I think we want to use and display the local tz naming of times that are actually 1h apart. So for the day in question, that's 0000 0100 0300 0400 and we want those to appear equi-spaced on the graph. With the try/except above, that I think will happen on systems where mktime rejects 0200. With systems where mktime of 0200 returns the time_t for 0300 (which is 3600 after the time_t for 0100), I think it will result in 0000 0100 0300 0300 0400 So I wonder about another if block that checks for interval == 3600 (or maybe <= 3600?) and just does straightforward time_t operations. For these intervals, a one hour change will not cause misrounding. I suppose there is the issue of DST shifts that are less than 1h, but my impression is that DST is always 1h or 2h, even if TZ offsets are :30 or :15. -- 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/rmi8sk8m9ae.fsf%40s1.lexort.com.
