Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8243541

(tz) Upgrade time-zone data to tzdata2020a

    Details

    • Subcomponent:
    • Resolved In Build:
      b21

      Backports

        Description

        [Fri Apr 24 04:30:20 UTC 2020]

        The 2020a release of the tz code and data is available. It reflects the
        following changes, which were either circulated on the tz mailing list or are
        relatively minor technical or administrative changes:

          Briefly:
            Morocco springs forward on 2020-05-31, not 2020-05-24.
            Canada's Yukon advanced to -07 year-round on 2020-03-08.
            America/Nuuk renamed from America/Godthab.
            zic now supports expiration dates for leap second lists.

          Changes to future timestamps

            Morocco's second spring-forward transition in 2020 will be May 31,
            not May 24 as predicted earlier. (Thanks to Semlali Naoufal.)
            Adjust future-year predictions to use the first Sunday after the
            day after Ramadan, not the first Sunday after Ramadan.

            Canada's Yukon, represented by America/Whitehorse and
            America/Dawson, advanced to -07 year-round, beginning with its
            spring-forward transition on 2020-03-08, and will not fall back on
            2020-11-01. Although a government press release calls this
            "permanent Pacific Daylight Saving Time", we prefer MST for
            consistency with nearby Dawson Creek, Creston, and Fort Nelson.
            (Thanks to Tim Parenti.)

          Changes to past timestamps

            Shanghai observed DST in 1919. (Thanks to Phake Nick.)

          Changes to timezone identifiers

            To reflect current usage in English better, America/Godthab has
            been renamed to America/Nuuk. A backwards-compatibility link
            remains for the old name.

          Changes to code

            localtime.c no longer mishandles timestamps after the last
            transition in a TZif file with leap seconds and with daylight
            saving time transitions projected into the indefinite future.
            For example, with TZ='America/Los_Angeles' with leap seconds,
            zdump formerly reported a DST transition on 2038-03-14
            from 01:59:32.999... to 02:59:33 instead of the correct transition
            from 01:59:59.999... to 03:00:00.

            zic -L now supports an Expires line in the leapseconds file, and
            truncates the TZif output accordingly. This propagates leap
            second expiration information into the TZif file, and avoids the
            abovementioned localtime.c bug as well as similar bugs present in
            many client implementations. If no Expires line is present, zic
            -L instead truncates the TZif output based on the #expires comment
            present in leapseconds files distributed by tzdb 2018f and later;
            however, this usage is obsolescent. For now, the distributed
            leapseconds file has an Expires line that is commented out, so
            that the file can be fed to older versions of zic which ignore the
            commented-out line. Future tzdb distributions are planned to
            contain a leapseconds file with an Expires line.

            The configuration macros HAVE_TZNAME and USG_COMPAT should now be
            set to 1 if the system library supports the feature, and 2 if not.
            As before, these macros are nonzero if tzcode should support the
            feature, zero otherwise.

            The configuration macro ALTZONE now has the same values with the
            same meaning as HAVE_TZNAME and USG_COMPAT.

            The code's defense against CRLF in leap-seconds.list is now
            portable to POSIX awk. (Problem reported by Deborah Goldsmith.)

            Although the undocumented tzsetwall function is not changed in
            this release, it is now deprecated in preparation for removal in
            future releases. Due to POSIX requirements, tzsetwall has not
            worked for some time. Any code that uses it should instead use
            tzalloc(NULL) or, if portability trumps thread-safety, should
            unset the TZ environment variable.

          Changes to commentary

            The Îles-de-la-Madeleine and the Listuguj reserve are noted as
            following America/Halifax, and comments about Yukon's "south" and
            "north" have been corrected to say "east" and "west". (Thanks to
            Jeffery Nichols.)

        Here are links to the release files:

          https://www.iana.org/time-zones/repository/releases/tzcode2020a.tar.gz
          https://www.iana.org/time-zones/repository/releases/tzdata2020a.tar.gz
          https://www.iana.org/time-zones/repository/releases/tzdb-2020a.tar.lz

        PS. If your tzdata parser does not yet support negative DST offsets or times
        past 24:00, this release's data entries can be turned into a rearguard-format
        tarball that does not use these features. This is intended to be a temporary
        transition aid for these parsers. To generate a rearguard-format tarball, obtain
        the full distribution as described above, and run the command 'make
        rearguard_tarballs' on a development host. Or you can run 'make rearguard.zi' to
        generate a single file that can be fed directly to a parser that works like 'zic'.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  kravikumar Kiran Sidhartha Ravikumar
                  Reporter:
                  kravikumar Kiran Sidhartha Ravikumar
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  7 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: