issues: 540399695
This data as json
id | node_id | number | title | user | state | locked | assignee | milestone | comments | created_at | updated_at | closed_at | author_association | active_lock_reason | draft | pull_request | body | reactions | performed_via_github_app | state_reason | repo | type |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
540399695 | MDU6SXNzdWU1NDAzOTk2OTU= | 3644 | Handling of non iso8601 format time | 13421074 | closed | 0 | 3 | 2019-12-19T15:52:19Z | 2019-12-19T16:46:18Z | 2019-12-19T16:46:18Z | NONE | MCVE Code Sample
Expected OutputTimestamp('2019-04-02 22:00:02') Actual OutputTimestamp('2019-04-02 00:00:00') Problem DescriptionThe default for decoding time is to use pandas Timestamp (_decode_datetime_with_pandas), however it appears that the pandas Timestamp function only handles iso8601 time format when passed as a string. Should there be a check on the format of the string before passing ref_date to Timestamp to ensure this does not return erroneous times without warning? The code sample above is a simple example where a format acceptable by udunits and used by the Atmospheric Radiation Measurement program, returns an erroneous time (00:00:00 instead of 22:00:02). use_cftime is an option and this is my fault for not knowing, but I did not know this was even an issue until we had time units that start at something other than 00:00 utc like: time:units = "seconds since 2019-04-02 22:00:02 0:00" ; Thank you ahead of time for review of this issue. I've search a lot over the past couple days to see if a related issue was open but had no luck. Apologies if I missed something. Output of
|
{ "url": "https://api.github.com/repos/pydata/xarray/issues/3644/reactions", "total_count": 0, "+1": 0, "-1": 0, "laugh": 0, "hooray": 0, "confused": 0, "heart": 0, "rocket": 0, "eyes": 0 } |
completed | 13221727 | issue |