[SERVER-48196] Upgrade the timelib to the latest to update the built-in timezone files to the latest Created: 13/May/20  Updated: 29/Oct/23  Resolved: 20/Jan/23

Status: Closed
Project: Core Server
Component/s: Aggregation Framework, Querying
Affects Version/s: 4.4.0
Fix Version/s: 6.3.0-rc0, 6.0.6, 4.4.22, 5.0.18

Type: Improvement Priority: Major - P3
Reporter: Charlie Swanson Assignee: Yoon Soo Kim
Resolution: Fixed Votes: 0
Labels: query-director-triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
depends on SERVER-44273 Failure to parse certain time zone sp... Closed
Problem/Incident
causes SERVER-78750 Fix Olsen timezone script to refer to... Closed
Related
related to SERVER-55725 Upgrade timelib to 2021.02 or later Closed
related to SERVER-60141 Upgrade timelib to 2021.09 or later Closed
Assigned Teams:
Query Execution
Backwards Compatibility: Minor Change
Backport Requested:
v6.3, v6.0, v5.0, v4.4
Sprint: QE 2022-10-31, QE 2022-11-14, QE 2022-11-28, QE 2022-12-12, QE 2022-12-26, QE 2023-01-09, QE 2023-01-23
Participants:
Case:

 Description   

There has been a new release 2022g of timezone files. We should consider upgrading the builtin timezone rules, and potentially backporting. 

This release includes the move of Mexico away from supporting DST (Daylight Saving Time)

Update: The original request was to update the built-in timezone files but it's preferred to upgrade a third party library as a whole for all third party libraries if there's an official release so as to avoid any hassles (mostly resolving merge conflicts between custom changes and vanilla version) to deal with custom changes to each third party library. So, we upgrade the whole timelib instead of updating only the built-in timezone files. But note that the timelib owner does not release a separate version for each timezone db release. So, probably we need to update timezone files only when there's no separate release. Still it would be worth asking the timelib owner whether he's willing to release a separate version even though there's no separate release yet.



 Comments   
Comment by Githook User [ 18/Apr/23 ]

Author:

{'name': 'Gil Alon', 'email': 'gil.alon@mongodb.com', 'username': 'galon1'}

Message: SERVER-48196 Upgrade the timelib to 2022.04 to update the built-in timezone files to 2022g
Branch: v4.4
https://github.com/mongodb/mongo/commit/77017fd320060f1f38f85d17828a1ea873b88f56

Comment by Githook User [ 17/Apr/23 ]

Author:

{'name': 'Gil Alon', 'email': 'gil.alon@mongodb.com', 'username': 'galon1'}

Message: SERVER-48196 Upgrade the timelib to 2022.04 to update the built-in timezone files to 2022g
Branch: v5.0
https://github.com/mongodb/mongo/commit/ed07a005361a2ec1fa8758eb41271c0cf66dca51

Comment by Githook User [ 12/Apr/23 ]

Author:

{'name': 'Yoonsoo Kim', 'email': 'yoonsoo.kim@mongodb.com', 'username': 'yun-soo'}

Message: SERVER-48196 Upgrade the timelib to 2022.04 to update the built-in timezone files to 2022g

(cherry picked from commit fdb3ed4c149c5eb38ae422f5fde4f29f411fdb07)
Branch: v6.0
https://github.com/mongodb/mongo/commit/19febe62397475c94ec3785222e48df089e1e714

Comment by Kyle Suarez [ 12/Apr/23 ]

yoonsoo.kim@mongodb.com, sure, I'll flag the backports for director triage and bernard.gorman@mongodb.com and I will find an assignee.

Comment by Yoon Soo Kim [ 06/Apr/23 ]

kyle.suarez@mongodb.com, is there any chance for anyone from the QE team to take backports? I have too many things on my plate and am a bit overwhelmed right now.

I recorded detailed steps that I followed. It should not be that hard to backport this.

Comment by Githook User [ 20/Jan/23 ]

Author:

{'name': 'Yoonsoo Kim', 'email': 'yoonsoo.kim@mongodb.com', 'username': 'yun-soo'}

Message: SERVER-48196 Upgrade the timelib to 2022.04 to update the built-in timezone files to 2022g
Branch: master
https://github.com/mongodb/mongo/commit/fdb3ed4c149c5eb38ae422f5fde4f29f411fdb07

Comment by Mohammad Dashti (Inactive) [ 19/Jan/23 ]

Yoon Soo, thanks for checking with Derick.

Also, while you are at it, it's best if you could remove the postfix from the lib directory name, i.e., the directory name should be timelib rather than timelib-2022.02. This approach is taken with all recent third-party library upgrades.

Comment by Mohammad Dashti (Inactive) [ 19/Jan/23 ]

yoonsoo.kim@mongodb.com As alberto.massari@mongodb.com suggested on Slack, it's preferable to avoid cherry-picking and do an entire library upgrade. It's worth contacting Derick and asking to create a release tag. If Derick doesn't make a release tag timely, it's fine to go with cherry-picking. The prior instances of cherry-picking were of this nature (which Derick was reluctant to create a release tag).

Comment by Kyle Suarez [ 19/Jan/23 ]

Updated the title to say we'd like the latest release possible, barring complications

Comment by Kyle Suarez [ 11/Nov/22 ]

I'll look for an engineer on the North America side (preferably someone who is just wrapping up a project) to pick this up.

Comment by James Wahlin [ 31/Oct/22 ]

Repurposing this ticket to handle an upgrade to 2022f which includes the change made by Mexico to not support DST, effective October 30th, 2022. 

 

The 2022f release of the tz code and data is available.

This release contains the following changes. The most urgent one is the
change for Chihuahua, Mexico which affects timestamps starting Sunday.

   Briefly:
     Mexico will no longer observe DST except near the US border.
     Chihuahua moves to year-round -06 on 2022-10-30.
     Fiji no longer observes DST.
     Move links to 'backward'.
     In vanguard form, GMT is now a Zone and Etc/GMT a link.
     zic now supports links to links, and vanguard form uses this.
     Simplify four Ontario zones.
     Fix a Y2438 bug when reading TZif data.
     Enable 64-bit time_t on 32-bit glibc platforms.
     Omit large-file support when no longer needed.
     In C code, use some C23 features if available.
     Remove no-longer-needed workaround for Qt bug 53071.

   Changes to future timestamps

     Mexico will no longer observe DST after 2022, except for areas
     near the US border that continue to observe US DST rules.
     On 2022-10-30 at 02:00 the Mexican state of Chihuahua moves
     from -07 (-06 with DST) to year-round -06, thus not changing
     its clocks that day.  The new law states that Chihuahua
     near the US border no longer observes US DST.
     (Thanks to gera for the heads-up about Chihuahua.)

     Fiji will not observe DST in 2022/3.  (Thanks to Shalvin Narayan.)
     For now, assume DST is suspended indefinitely.

   Changes to data

     Move links to 'backward' to ease and simplify link maintenance.
     This affects generated data only if you use 'make BACKWARD='.

     GMT is now a Zone and Etc/GMT a link instead of vice versa,
     as GMT is needed for leap second support whereas Etc/GMT is not.
     However, this change exposes a bug in TZUpdater 2.3.2 so it is
     present only in vanguard form for now.

     Vanguard form now uses links to links, as zic now supports this.

   Changes to past timestamps

     Simplify four Ontario zones, as most of the post-1970 differences
     seem to have been imaginary.  (Problem reported by Chris Walton.)
     Move America/Nipigon, America/Rainy_River, and America/Thunder_Bay
     to 'backzone'; backward-compatibility links still work, albeit
     with some different timestamps before November 2005.

   Changes to code

     zic now supports links to links regardless of input line order.
     For example, if Australia/Sydney is a Zone, the lines
       Link Australia/Canberra Australia/ACT
       Link Australia/Sydney Australia/Canberra
     now work correctly, even though the shell commands
       ln Australia/Canberra Australia/ACT
       ln Australia/Sydney Australia/Canberra
     would fail because the first command attempts to use a link
     Australia/Canberra that does not exist until after the second
     command is executed.  Previously, zic had unspecified behavior if
     a Link line's target was another link, and zic often misbehaved if
     a Link line's target was a later Link line.

     Fix line number in zic's diagnostic for a link to a link.

     Fix a bug that caused localtime to mishandle timestamps starting
     in the year 2438 when reading data generated by 'zic -b fat' when
     distant-future DST transitions occur at times given in standard
     time or in UT, not the usual case of local time.  This occurs when
     the corresponding .zi Rule lines specify DST transitions with TO
     columns of 'max' and AT columns that end in 's' or 'u'.  The
     number 2438 comes from the 32-bit limit in the year 2038, plus the
     400-year Gregorian cycle.  (Problem reported by Bradley White.)

     On glibc 2.34 and later, which optionally supports 64-bit time_t
     on platforms like x86 where time_t was traditionally 32 bits,
     default time_t to 64 instead of 32 bits.  This lets functions like
     localtime support timestamps after the year 2038, and fixes
     year-2038 problems in zic when accessing files dated after 2038.
     To continue to limit time_t to 32 bits on these platforms, use
     "make CFLAGS='-D_TIME_BITS=32'".

     In C code, do not enable large-file support on platforms like AIX
     and macOS that no longer need it now that tzcode does not use
     off_t or related functions like 'stat'.  Large-file support is
     still enabled by default on GNU/Linux, as it is needed for 64-bit
     time_t support.

     In C code, prefer C23 keywords to pre-C23 macros for alignof,
     bool, false, and true.  Also, use the following C23 features if
     available: __has_include, unreachable.

     zic no longer works around Qt bug 53071, as the relevant Qt
     releases have been out of support since 2019.  This change affects
     only fat TZif files, as thin files never had the workaround.

     zdump no longer modifies the environ vector when compiled on
     platforms lacking tm_zone or when compiled with -DUSE_LTZ=0.
     This avoid undefined behavior on POSIX platforms.

Here are links to the release files:

   https://www.iana.org/time-zones/repository/releases/tzcode2022f.tar.gz
   https://www.iana.org/time-zones/repository/releases/tzdata2022f.tar.gz
   https://www.iana.org/time-zones/repository/releases/tzdb-2022f.tar.lz

The following convenience links are also available, although they may
point to the previous release until the relevant caches are refreshed:

   https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz
   https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz
   https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz

Links are also available via plain HTTP, and via FTP from
ftp://ftp.iana.org/tz/releases with the same basenames as above.

Each release file has a GPG signature, which can be retrieved by
appending ".asc" to the above URLs. Copies of these signatures are
appended to this message.

This release corresponds to commit
d3dc2a9d65ce433555c994ce2cf84901b87d9357 dated 2022-10-28 18:04:57 -0700
and tagged '2022f' in the development GitHub repository at
<https://github.com/eggert/tz>.

Comment by Craig Homa [ 26/May/20 ]

Assigning to QO to triage due to its relationship to SERVER-44273. Storch thinks the priority will be low once 44273 is fixed.

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