Error parsing midnight date/time
eddiecraig opened this issue · 6 comments
End time of highlighted TEMPO group not correctly returning "dt" field:
CYVO 061738Z 0618/0706 07005KT P6SM -SN OVC060 TEMPO 0618/0620 3SM -SN BKN030 OVC060 FM062000 06008KT 11/2SM -SN OVC012 TEMPO 0620/0624 6SM -SN OVC025 FM070000 03005KT P6SM -SN OVC025 TEMPO 0700/0702 21/2SM -SN OVC015 FM070200 03005KT P6SM -SN OVC025 PROB30 0702/0704 3SM -FZDZ BR RMK NXT FCST BY 070000Z
"end_time": { "repr": "0624", "dt": "Wed, 06 Feb 2019 00:00:00 GMT" }
Confusingly "0624" represents "Thu, 07 Feb 2019 00:00:00 GMT". ie it should wrap around to midnight the next day. "0600" represents "Wed, 06 Feb 2019 00:00:00 GMT".
Also, could consideration be given to returning the "dt" field as an ISO 8601 date for unambiguous compatibility with more clients? I'm pretty sure python has an isoformat method on datetime objects. It's more succinct while retaining readability. Discussion here:
https://stackoverflow.com/questions/10286204/the-right-json-date-format
The “0624” fix is going to be stuck behind an avwx-engine feature release, but I can update the datetime response format tonight. Been meaning to do that
The datetime format fix has been pushed
Nice. The times are currently being returned with no timezone information which ambiguously makes them 'local' time. I think UTC can be set as the timezone of a datetime to produce the correct output (or simply append a "Z" character to the end of the string!)
Agreed since even user-supplied timestamps are assumed to be Zulu. Should see them updated in a few minutes
There seems to have been a regression to incorrectly parsing end of day midnight datetimes.
EGLL 211654Z 2118/2224 26010KT 9999 FEW040 BECMG 2204/2207 20006KT
Parses as:
"end_time": { "repr": "2224", "dt": "2020-06-22T00:00:00Z" }
Rather than:
"end_time": { "repr": "2224", "dt": "2020-06-23T00:00:00Z" }
The example TAF from KJFK in the documentation at https://avwx.docs.apiary.io/#reference/0/taf/get-taf-report contains a similar parsing error.
I fixed the issue and added a test for this exact instance here:
https://github.com/avwx-rest/avwx-engine/blob/master/tests/parsing/test_core.py#L361
The fix will be pushed soon.