Daylight savings changeovers at midnight cause problems with daily summaries

[gjr80]

This thread refers.

Stations using Brazilian time and observing daylight savings encounter an error around the date when daylight savings starts. The error manifests itself with the error message:

NoColumnError: no such column: wind

This error is the result of weeutil.weeutil.isMidnight() interpreting the timestamp for midnight at the start of the day on which daylight savings starts as 1am (01:00:00) rather than midnight (00:00:00). Thus the archive is used for any .wind tags and thus the error message. The error will occur in the leadup to daylight savings (when a .wind tag timespan stop timestamp lands on the day of the start of daylight savings), as well as the day of the start of daylight savings and for the rest of the month due to the NOAA format reports month report iterating over all days in the month. The error appears to be presentation related only with no affect on the archive data.

It is suspected that this issue will also affect any other locality where daylight savings starts at midnight.

This issue was reported by a user in Brazil in 2015 in this thread but it appears the issue was never addressed.

[tkeffer]

I struggled to find a solution for this problem, and finally came up with something.

The problem is not whether a time "is midnight," but whether it is the start of a day. Recognizing this, the algorithm calculates what day the time belongs to. It then calculates what day a tenth of a second earlier belongs to. If they match, it must not be the start of the day.

    dt1 = datetime.date.fromtimestamp(time_ts)
    dt2 = datetime.date.fromtimestamp(time_ts - .1)
    return not dt1 == dt2

It's a bit of a kludge, but it works.

Implemented in commit 0a5ee55