import_green_button_xml daylight savings time exception

[mcwp]

Since my green button data uses local time, it duplicates an hour in the fall, causing an exception in importers.import_green_button_xml when end < start time.

This fix works for my testing purposes:

• if end <= start:

• end of daylight savings time, so add an hour

• end = datetime.fromtimestamp(end_s + 3600)

[philngo]

@jpvelez is working on a better green button importer, so let's pull him in to this conversation. I hunch is that the deeper issue here is that we're using timezone naive datetimes. The fix above would probably work in most cases, but if we handled the timezones appropriately, we wouldn't have to add the extra seconds, which might not be the appropriate thing to do for truly malformed data, which is what this little block is trying to catch.

https://github.com/impactlab/eemeter/blob/a1ddd1e7c28e38c72d4e2a78abc5710d857d7301/eemeter/consumption.py#L411-L414

In addition to fixing the importer, we should stick a little extra logic in the ConsumptionData creation step that strictly prohibits timezone naive datetime objects in the records data.

[mcwp]

Possibly important detail: I ran into this problem when calling import_green_button_xml from the python shell. I passed it in a file containing my gb data from 2013-06-01 to 2016-03-01. For each of three years, the end is < start at 1:45am in early November. :-)

I notice that the fake data in get_example_project passes in tzinfo=pytz.utc.