[DOCS-16090] [SERVER] $dateToString outputs invalid ISO8601 string Created: 02/May/23 Updated: 13/Nov/23 Resolved: 13/Sep/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual, Server |
| Affects Version/s: | 6.0.3 |
| Fix Version/s: | 7.1.0-rc0, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113 |
| Type: | Task | Priority: | Critical - P2 |
| Reporter: | Backlog - Core Eng Program Management Team | Assignee: | Nick Villahermosa |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | query, release | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 21 weeks ago | ||||||||
| Description |
|
ORIGINAL TITLE: Investigate changes in Original Downstream Change Summary The current default behavior of MongoDB's $dateToString aggregation expression is incorrect because it violates ISO 8601. (It tacks on a "Z" to the end of the string by default, which implies that it is in UTC [1], but in actually it's in the timezone of the local server.) This ticket proposes a number of routes to change the default behavior of $dateToString to bring it into compliance with ISO 8601. [1] https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal_Time_(UTC) Description of Linked TicketWhen using the $dateToString aggregation operator on an ISODate value, specifying a timezone but not a format string, an invalid/inaccurate ISO8601 date string is returned. Specifically: 2023-04-26T12:06:17.194Z when using something like:
The root issue is that the "Z" categorically implies a timezone of UTC (+00:00)... But, in this case, that's absolutely incorrect and, technically, makes it an invalid ISO8601 date string. (I suppose one could argue that it's syntatically valid - but it's certainly misleading and could result in major issues if another program were to parse the date string as it would interpret the time as "Zulu"/UTC because of the "Z".) The inclusion of the "Z" when explicitly specifying a timezone is certainly unexpected... At a minimum, when a format string is unspecified and a date/time in UTC is converted to another time zone, the "Z" should be left off. Ideally, the UTC offset (obtained from the timezone conversion) should be included as per ISO8601 – i.e. in this case, 2023-04-26T12:06:17.194-04:00 (at the time of this writing, America/New_York is on Eastern Daylight Time (EDT) which is UTC-04:00.) Related issues appear to include: |
| Comments |
| Comment by Nick Villahermosa [ 13/Sep/23 ] |
|
No backports, as code change isn't backported |