[SERVER-31851] Issue a warning when Olson time zone db versions do not match Created: 07/Nov/17  Updated: 06/Dec/22  Resolved: 29/Dec/17

Status: Closed
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: David Storch Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query
Participants:

 Description   

Each node in the cluster can separately use the timeZoneInfo configuration parameter to point to time zone information. Users could easily misconfigure their cluster to have different versions of the Olson time zone db on different nodes. This is not a fatal misconfiguration, but it could cause time calculations to be incorrect. We should attempt to proactively detect this misconfiguration and issue a warning.



 Comments   
Comment by David Storch [ 07/Nov/17 ]

milkie, I'm aware that this clearly needs to be thought through and specified in more detail. Implementing this could be significant work. I don't think we even surface the time zone db version information right now, plus we need to do the work of figuring out when and how to detect a version mismatch. I doubt it makes sense on startup, but perhaps it makes sense on connection setup? But then how do we avoid spamming the logs with warnings whenever two nodes with different Olson versions communicate?

From derick:

That's not particularly easy to do, as timezone files don't include the
Olson version number.

For distribution's tz packages, it is also not easy to obtain as it
would require interfacing with the individual packaging systems.

It is easy enough to detect when using the built-in timezone database,
as src/third_party/timelib-2017.05beta6/timezonedb.h includes:

const timelib_tzdb timezonedb_builtin = { "2017.2", 594, timezonedb_idx_builtin, timelib_timezone_db_data_builtin };

To which you can get to with "timelib_builtin_db()".

This would also not have been a problem if we would have picked the
"timezonedb as a single file" idea that I floated during the design
phase. But I guess that ship has sailed now.

Comment by Eric Milkie [ 07/Nov/17 ]

Where would the warning go? (Into the system log of every node?)
Or would it go into startup_warnings.. in which case, would it stick there forever, or would we eventually clear it out?
How often would we scan all the known nodes in a replica set for time zone db versions?

Generated at Thu Feb 08 04:28:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.