This probably needs to be done on an api-interface
by api-interface basis (as how we do it depends on
how we convert whatever comes back into a datetime
object). For the ciuk we have explicit UTC returned
but strptime does not know how to parse this. So
add the timezone info for each datetime object.

Also modify the test to make sure all datetime
objects we get back from the api_query are aware
of their datetime (we don't care what this is,
only that it is defined). We can then convert to
system time at the other end.

Make all test data going into the unit tests for
WindowedForcast have a timezone (specifically
UTC) and add that timezone to the expected output.
The existing assert statments will fail if timezone
data does not match.

As far as I can tell, when using the posix timestamp
to at, it works in local system time (which for me is
BST). So make all our start times and reports from the
optimiser timezone aware and in local system time. It
turns out that all we need to do to do this is feed in
a start time that is timezone aware and in the right
timezone. Doing this shifts the time that gets passed
generated for feeding into at by 1 hr, which is what we
want.

Also add a test case to test_windowed_forecast to make
sure that this all works. Note that we have to explicitly
check the timezones as the same time with different timezones
compare equal.

This documents the need for two checks for timezone awarness,
and makes one of the more complex forecast checks cross timezones
between the data and 'system' time.