Enforce ISO 8601 compliant timestamps

[ubergesundheit]

I am seeing timestamp results which confuse me a little.

For parameters tz=Europe/Berlin&date=2020-09-03T21:00:00+02:00&last_date=2020-09-04T08:00:00+02:00, I'm confused by seeing the first result to start 19 hours before the actual time in the date parameter.

Experimenting with different other values for date (2020-09-03T15:00:00+02:00) yields a weather record with the same timestamp as before (2020-09-03T02:00:00+02:00)

Omitting the +02:00 from the date and last_date parameters seems to work though..

curl example

curl "https://api.brightsky.dev/weather?lat=51.96&lon=7.62&tz=Europe/Berlin&date=2020-09-03T21:00:00+02:00&last_date=2020-09-04T08:00:00+02:00"
{
  "weather": [
    {
      "timestamp": "2020-09-03T02:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T03:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T04:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T05:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T06:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T07:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T08:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T09:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T10:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T11:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T12:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T13:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T14:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T15:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T16:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T17:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T18:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T19:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T20:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T21:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T22:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-03T23:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-04T00:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-04T01:00:00+02:00",
      ...
    },
    {
      "timestamp": "2020-09-04T02:00:00+02:00",
      ...
    }
  ],
  "sources": [
    ...
  ]
}

[jdemaeyer]

Heyho @ubergesundheit!,

you are not properly percent-encoding your URL query, use %2b instead of + :)

https://api.brightsky.dev/weather?lat=51.96&lon=7.62&date=2020-09-03T19:00%2b02:00&last_date=2020-09-04T08:00:00%2b02:00

[ubergesundheit]

Yes thanks! I thought curl would encode the url automatically ¯\_(ツ)_/¯

Maybe you could mention this in the docs or make the api return an error since the behaviour with the unescaped + seems a little buggy

[jdemaeyer]

Yeah, we're adopting some weird parsing behaviour from upstream here

>>> import dateutil.parser
>>> dateutil.parser.parse('2020-09-03T15:00:00 02:00')
datetime.datetime(2020, 9, 3, 2, 0)

I'll look into stronger enforcing of ISO8601-compliant timestamps

[jdemaeyer]

We're now enforcing ISO 8601 timestamps but will auto-correct if users forgot to URL-encode + as %2b.

While this is technically backwards-incompatible, it falls more into the category of "bug fix" and not "breaking change" -- our docs have always clearly said that timestamps need to be ISO-8601-formatted. However, if we see too many HTTP 400s after releasing this I'll revert to the previous non-enforcing/wrong parsing with all the unexpected behaviour it had.