refiito
commented
7 years ago Sorry, we introduced a bit of an optimisation that has this nasty side effect.
A fix will be rolled tomorrow early morning (UTC time), so, everything shall be back to what it was after that. Sorry again.
My usecase is the following: I am reading and processing Toggl entries using the Api described here https://github.com/toggl/toggl_api_docs/blob/master/toggl_api.md , as JSON. I am using the API version 8, endpoint https://www.toggl.com/api/v8/time_entries/<togglid>
Now, it seems that the start date of an entry does not always use the same format, namely the "time-secfrac" part (described by section 5.6 from http://www.ietf.org/rfc/rfc3339.txt ) seems to be sometimes there, sometimes missing. I.e. I receive both dates like: 2017-08-16T08:25:05.943+00:00 and 2017-08-16T09:00:00+00:00 (note that the ".943" part is present in the first date but not in the second). As far as I could test, when an entry is created with automatic mode (starting timer then stopping), the time-secfrac part is added. When an entry is created with manual mode (filling in both start and end time and date of the entry), the time-secfrac part is missing.
Now, this is bothering for a couple of reasons: 1/ even if the time-secfrac is marked optional by the RFC, it's quite difficult to work with 2 different date formats, not knowing when should one be used and when should the other be used to parse data 2/ it seems that the presence of this time-secfrac part is new, I have written my script around february 2016 with a date parser without time-secfrac and I have been using it ever since without ever hitting a date parsing issue until recently (for both automatic and manual entries) 3/ the examples in the documentation here https://github.com/toggl/toggl_api_docs/blob/master/toggl_api.md#successful-requests have no time-secfrac in the date entries