Issue 1: When consumption() is passed an aware datetime object (one that has a timezone), it ignores the timezone and treats the datetime as if it were naive (i.e. in the local timezone).
Issue 2: When consumption() is passed a naive datetime object (one with no timezone), it assumes that the timezone is the timezone of the device itself, even though convention is that naive datetime objects reflect the timezone of the running process.
Issue 1 (but not issue 2) can be fixed with a simple change where startDate is replaced by
datetime.fromtimestamp(startDate.timestamp()) and similarly for endDate. If we did this, consumption() will work correctly whenever the running process is in the same timezone as the device.
Both issues could be fixed by converting startDate and endDate to aware datetime objects in UTC, and then passing UTC time strings (ending in Z) to the Flo endpoint.
Happy to send a pull request and/or test any changes.
Issue 1: When consumption() is passed an aware datetime object (one that has a timezone), it ignores the timezone and treats the datetime as if it were naive (i.e. in the local timezone).
Issue 2: When consumption() is passed a naive datetime object (one with no timezone), it assumes that the timezone is the timezone of the device itself, even though convention is that naive datetime objects reflect the timezone of the running process.
Issue 1 (but not issue 2) can be fixed with a simple change where startDate is replaced by datetime.fromtimestamp(startDate.timestamp()) and similarly for endDate. If we did this, consumption() will work correctly whenever the running process is in the same timezone as the device.
Both issues could be fixed by converting startDate and endDate to aware datetime objects in UTC, and then passing UTC time strings (ending in Z) to the Flo endpoint.
Happy to send a pull request and/or test any changes.