Describe the bug

This library appears to use timezone-naive math internally so if you pass datetime objects that are timezone aware, it fails with a slightly cryptic error. It also isn't obvious that the datetime objects are expected to represent timezone-naive UTC.

Accepting timezone-naive objects seems like it creates a lot of unnecessary potential for weird bugs and confusion.

To Reproduce

Pass a datetime object with tzinfo set to run_forecast.

Expected behavior

This library should accept timezone aware datetime objects and return timezone aware datetime objects so consumers don't have to guess that they need to convert to UTC and drop the tzinfo and can get back datetime objects that are easier to use / unambiguous.

Additional context

N/A