The client now checks whether the first ambiguous hour value (e.g. "5:00 AM") falls either 24 hours before the report generation datetime during standard time or 25 hours before the report generation datetime during daylight savings. This fixes the bug that showed up during the recent transition back to standard time.
If it's neither 24 nor 25 hours before the report generation datetime, the client gives up and throws a RuntimeException, similar to before, so that it's not silently generating erroneous data.
Unit tests have been added with example HTML responses during daylight savings time (existing fixtures) and during standard time (new fixture). (They work for me locally and will work on the build server after #176 is merged. I expect that the first CI test run triggered by this pull request will fail until #176 is merged to master.)
Coverage increased (+0.1%) to 57.834% when pulling 2be1e3798565feefe9938514347c4bce8078f0b8 on r24mille:177_yukon_dst_issue into b3fd60fc05e32eb9464a4d5d01bc214b5d8eb11b on WattTime:master.
The client now checks whether the first ambiguous hour value (e.g. "5:00 AM") falls either 24 hours before the report generation datetime during standard time or 25 hours before the report generation datetime during daylight savings. This fixes the bug that showed up during the recent transition back to standard time.
If it's neither 24 nor 25 hours before the report generation datetime, the client gives up and throws a RuntimeException, similar to before, so that it's not silently generating erroneous data.
Unit tests have been added with example HTML responses during daylight savings time (existing fixtures) and during standard time (new fixture). (They work for me locally and will work on the build server after #176 is merged. I expect that the first CI test run triggered by this pull request will fail until #176 is merged to
master
.)Fixes #177.