Tom Keffer <[email protected]> writes: > WeeWX uses time.mktime() > <https://docs.python.org/3/library/time.html#time.mktime> to convert from > local time to UTC. This function takes a "time tuple", one of whose fields > is tm_isdst. You're supposed to fill this field out with whether DST is > active or not but, of course, we don't know because the Vantage won't tell > us. So, we use "-1" which indicates that the system should figure it out. > Usually it gets the right answer. Here's what it looks like during the DST > transition 14-Mar-2021 here in the USA: > >>>> from time import mktime >>>> mktime((2021,3,14,1,0,0,0,0,-1)) > 1615712400.0 >>>> mktime((2021,3,14,2,0,0,0,0,-1)) > 1615716000.0
There is no 2 AM, so mktime should be throwing an error. (It does actually throw an error on NetBSD.) If you take the returned value from the 0300 mktime call and convert it back with localtime, you get 3 (my time_t numbers are different because of being in Boston). On GNU/linux libc mktime appears to take the perhaps helpful but non-standard position of returning a time_t anyway. At 0200 exactly this is one thing, but at say 0230 it's something else entirely. This is I am pretty sure what causes my graph generation to fail on spring forward days. I realize this email doesn't contain a patch to catch the exception and skip the graph point :-) -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/rmizgymb030.fsf%40s1.lexort.com.
signature.asc
Description: PGP signature
