[GODRIVER-1328] Loosen strictness of date parsing in the driver Created: 02/Oct/19 Updated: 28/Oct/23 Resolved: 08/Oct/19 |
|
| Status: | Closed |
| Project: | Go Driver |
| Component/s: | JSON & ExtJSON |
| Affects Version/s: | None |
| Fix Version/s: | 1.2.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | May Hoque | Assignee: | Divjot Arora (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Description |
|
Currently, it seems that the Go driver is quite strict in enforcing RFC3339 format for its dates, but the docs mention that dates conform to the more looser superset of ISO8601. The Python driver seems to be more lenient with this and allows valid ISO8601, but is strict in its output and will give back RFC3339. This is currently affecting a customer for Atlas Data Lake, who is using ISO8601 date format that is in conflict with RFC3339, and is causing errors when using the Go driver to parse their JSON. |
| Comments |
| Comment by Divjot Arora (Inactive) [ 03/Oct/19 ] | |
| Comment by David Golden [ 02/Oct/19 ] | |
|
That should be straightforward to address. If the time.Parse call with rfc339Milli fails, we can try parsing "2006-01-02T15:04:05.999Z0700" as a fallback. | |
| Comment by Craig Wilson [ 02/Oct/19 ] | |
|
They are using this format, which is apparently exported from Studio 3T:
| |
| Comment by Bernie Hackett [ 02/Oct/19 ] | |
|
Note that the Python driver's loose parsing of dates basically evolved to support all the different formats mongoexport has generated over the last 10 years, rather than strictly following the RFC section David points to (the Python driver is probably even more loose than the RFC requires). It is probably not the best guide. | |
| Comment by David Golden [ 02/Oct/19 ] | |
|
Some context on the spec: ISO 8601 is a huge family of formats. The normative part of the Extended JSON spec says
Where footnote 4 links to here: https://tools.ietf.org/html/rfc3339#section-5.6 – that's intended to be a lowest-common-denominator set of allowed date formats because mandating all of ISO 8601 isn't necessarily feasible across all drivers. (You can read in the RFC about some of the problems with ISO 8601.) What specifically are they using that isn't compatible with RFC-3339? |