[SERVER-60141] Upgrade timelib to 2021.09 or later Created: 22/Sep/21  Updated: 29/Oct/23  Resolved: 26/Sep/22

Status: Closed
Project: Core Server
Component/s: Query Execution
Affects Version/s: None
Fix Version/s: 6.0.3, 6.2.0-rc0

Type: Improvement Priority: Minor - P4
Reporter: Mohammad Dashti (Inactive) Assignee: Alberto Massari
Resolution: Fixed Votes: 0
Labels: timelib
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-68289 Avoid excessive allocations in timeli... Closed
depends on SERVER-68331 Accelerate individual steps in the da... Closed
Duplicate
is duplicated by SERVER-44278 Upgrade timelib to 2018.03 Closed
Problem/Incident
causes SERVER-70209 List new timelib library in 3rd-party... Closed
Related
is related to SERVER-59701 Error when working with some timezone... Closed
is related to SERVER-48196 Upgrade the timelib to the latest to ... Closed
Backwards Compatibility: Minor Change
Backport Requested:
v6.0, v5.0, v4.4
Sprint: QE 2022-01-10, QE 2022-02-07, QE 2022-02-21, QE 2022-01-24, QE 2022-09-19, QE 2022-10-03
Participants:

 Description   

As part of SERVER-59701, we applied a custom change to timelib and it's currently a PR on the timelib's repo: https://github.com/derickr/timelib/pull/117

We expect this change gets included in timelib 2021.09. This upgrade will make sure that we don't have to maintain any custom change from timelib by ourselves.



 Comments   
Comment by Githook User [ 25/Oct/22 ]

Author:

{'name': 'Alberto Massari', 'email': 'alberto.massari@mongodb.com', 'username': 'albymassari'}

Message: SERVER-60141 Upgrade timelib to version 2022.02
Branch: v6.0
https://github.com/mongodb/mongo/commit/e7571d00d04b8a3b579047b726b7c6c24cfc3ed4

Comment by Alberto Massari [ 26/Sep/22 ]

The new timelib library fixes a bug in the computation of the week day for dates before 1 A.D.. This affects dayOfWeek, isoDayOfWeek, week and dateDiff(.."week"..). These years should not be used in real case scenarios, though

Comment by Githook User [ 26/Sep/22 ]

Author:

{'name': 'Alberto Massari', 'email': 'alberto.massari@mongodb.com', 'username': 'albymassari'}

Message: SERVER-60141: Upgrade timelib to version 2022.02
Branch: master
https://github.com/mongodb/mongo/commit/67a20e1aae8124adfcc4f0c3d448d98c49f74c69

Comment by Kyle Suarez [ 02/Mar/22 ]

This ticket got lost on the backlog; flagging for retriage.

Comment by Mohammad Dashti (Inactive) [ 30/Sep/21 ]

david.storch I agree with you. I'll put it back in the backlog. We need to reschedule it once a new release of timelib becomes available.

Comment by David Storch [ 29/Sep/21 ]

I don't see a huge rush to get 2021b or any other particular version of the tz db into the embedded copy of the tz data in mongod. Users can always use --timeZoneInfo if they need a different version of the tz db. I think we can put this ticket back in the triage queue, and preferably mark it so that it can be revisited in a quarter or so. It seems overall easier to just stay in sync with timelib and allow Derick to cut timelib releases at his natural cadence. We just have to remember to upgrade the vendored copy of timelib regularly so that we don't fall behind!

Comment by Mohammad Dashti (Inactive) [ 28/Sep/21 ]

Also, here's another reply from Derick on https://github.com/derickr/timelib/pull/117

I don't really want to make a release for each single line that I change. For now, I recommend you just patch this yourself if it's important enough.

Then, there's nothing to be updated for now. I'll move this ticket to the "Blocked" state. We can also close it for now and re-open it later.

Comment by Mohammad Dashti (Inactive) [ 28/Sep/21 ]

david.storch I opened a ticket for this this: https://github.com/derickr/timelib/issues/118

Here's the response from Derick:

There is no need to open tickets for this. I keep track of this myself.

The reason why I haven't updated it yet is that the TZ Coordinator has pushed dubious changes to the TZ repository that removes certain pre-1970 transitions. Or rather, makes some TZIDs use information from other areas as their pre-1970 transitions. This would have made the Europe/Oslo (Norway) zone use pre-1970 transitions from Germany (Europe/Berlin), for example. Some of these have been reverted, for now. I expect that the TZ Coordinator will want to try to push this again in the future, which will be a massive headache for downstream projects. I don't want to remove that data for PHP users, as it's not backwards compatible, but if I don't then the TZ data that is available through the OS will get out of sync with what PHP and timelib bundle. That's not an ideal situation either, and will impact MongoDB users too if they sometimes use bundled data, and some times OS data.

This is a BC break and I haven't put things through QA yet for PHP to see how much this will break. So you'll have to bear with me for a while to make sure it does not impact a lot.

Then, I don't see it happening soon. Do you think we should wait for it?

Comment by David Storch [ 28/Sep/21 ]

There is also a recent 2021b release of the IANA timezone db: https://www.iana.org/time-zones. We should make sure that the embedded version of the timezone db is at least 2021b when we do this work.

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