Make datetime processing more robust and uniform

Er leken toch nog wel wat problemen met datetime's te zijn in get_model_input() en get_predictors(). Deze PR probeert deze issues op te lossen.

een default timezone wordt toegevoegd als er geen timezone informatie is
- zowel aan start en end datetime als de datetime_index
De start en eind tijd wordt altijd afgerond naar de gevraagde resolutie (bijv. 15min)
De start en eind tijd wordt afgeleid uit de gegenereerde index zodat deze altijd goed zijn.

Laat maar horen of dit een goede oplossing is. (Het zou misschien nog wat verder uitgerold moeten worden ??) Misschien kan het nog makkelijker? Je wilt gewoon één functie call hebben om je datumtijd dingen goed te zetten denk ik. Misschien moeten we nog stricter zijn en bijv. ook pytz.UTC omzetten naar timezone.utc dat we maar één formaat UTC accepteren. Of misschien willen we het wel andersom pytz.UTC de default maken.

TODO

Eventueel alle datetime manipulaties in get_weather_data gelijk trekken
Use cases uitwerken en testen
- niet afgeronde datetime's als input
- Geen tijdzone informatie
- Andere tijdzone informatie (geen default timezone.utc)
- getest met timezone.utc en pytz.UTC, beide lijken nu goed te werken
- Bepalen wat de default timezone is (nu timezone.utc misschien is pytz.utc toch beter?)
- Unit/integratie testen maken
- Alle datetime argumenten zijn hetzelfde type: datetime lijkt voor de hand liggend.
- docstrings updaten
- Altijd dezelfde datetime to str conversie toepassen waarschijnlijk isoformat() (misschien anders voor mysql en influxdb?)
- Default start en end datetimes worden op dezelfde manier gemaakt voor alle functies.

OpenSTEF / openstef-dbc

Make datetime processing more robust and uniform #10