[SERVER-64788] some server log timestamps switch to UTC+DST after startup Created: 22/Mar/22 Updated: 06/Dec/22 |
|
| Status: | Open |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Backlog - Service Architecture |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Service Arch
|
| Operating System: | ALL |
| Participants: |
| Description |
|
Mongod is somehow sensitive to DST and putting out timestamps at +01:00, which is not technically an incorrect timestamp but it isn't useful and doesn't line up vertically. We're clearly trying to put timestamps in GMT and failing. This behavior seems to start at some point during server initialization, and doesn't affect all executables. mongobridge is unaffected, for example.
Somewhere between these lines, the mongod changed timezone. |
| Comments |
| Comment by Githook User [ 25/Mar/22 ] | ||||||||
|
Author: {'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}Message: SERVER-64788 demystify time_support_test | ||||||||
| Comment by Billy Donahue [ 23/Mar/22 ] | ||||||||
|
I wonder if this code is the culprit. Shouldn't the struct tm be zeroed out before use? https://github.com/mongodb/mongo/blob/master/src/mongo/util/time_support.cpp#L164
| ||||||||
| Comment by Billy Donahue [ 22/Mar/22 ] | ||||||||
|
henrik.edin any ideas? I don't see anything obvious. It appears that at some point in initialization we switch the server to local time. If the buildhosts are set to UTC, I still don't understand how a DST offset of +01:00 would appear in logs, as UTC doesn't observe DST. Maybe buildhosts are misconfigured.
Aside, this does bring up an issue that if local, we use a numeric offset, otherwise "Z". We do this even if the numeric offset happens to be zero. We also could try to identify the zero offset and represent it with "Z" instead of a "+00:00". |