[SERVER-39600] Server-Updated Timestamp Does Not Follow Local Time Created: 15/Feb/19 Updated: 25/Feb/19 Resolved: 25/Feb/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | JavaScript |
| Affects Version/s: | 3.6.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Simon Yarde | Assignee: | Gabriel Russell (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Sprint: | Dev Tools 2019-03-11 |
| Participants: |
| Description |
|
Something strange with server-updated Timestamps. Unsure if this is a bug or expected behaviour that is not documented re interaction with timezones. Observed in NodeJS driver and confirmed in shell (e.g. below). Timestamps are being created +1 hour ahead of system localtime. I believe mongod should always use UTC. Otherwise, daylight saving time zones would break ordering guarantees. Why is mongod creating timestamps using UTC+1 instead of UTC?
|
| Comments |
| Comment by Gabriel Russell (Inactive) [ 25/Feb/19 ] | ||||||||||||
|
simony This does indeed appear to be an upstream spidermonkey bug. I've filed a ticket against their project, https://bugzilla.mozilla.org/show_bug.cgi?id=1530538 . Besides the workaround that Kelsey recommended, I can offer another alternative. setTime() looks like the more correct way to set the time on a date object, and appears to work correctly. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/setTime | ||||||||||||
| Comment by Simon Yarde [ 16/Feb/19 ] | ||||||||||||
|
Hi Kelsey Thanks for your quick reply and workaround. This is really helpful to our current project. To confirm MongoDB is correctly storing UTC/GMT time on my system:
Best Regards Simon | ||||||||||||
| Comment by Kelsey Schubert [ 16/Feb/19 ] | ||||||||||||
|
Hi simony, Thanks for the report and repro. After changing my local timezone to Europe/London, I was able to reproduce this behavior on my linux machine. The issue appears to be upstream of MongoDB, most likely in SpiderMonkey. Consider this simplified repro in the mongo shell that does no writes to the database:
Note that in your case, MongoDB is storing and returning the correct values in UTC, and using the setUTCSeconds method in your repro will confirm the correct result.
I'm assigning this to the Dev Tools team to schedule a deeper investigation of the root cause of this issue to open a bug report upstream and apply the fix. Kind regards, |