Source-Changes-HG archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[src/trunk]: src/lib/libc/time Welcome tzcode-2018g
details: https://anonhg.NetBSD.org/src/rev/2a4f552d4bac
branches: trunk
changeset: 445409:2a4f552d4bac
user: christos <christos%NetBSD.org@localhost>
date: Sat Oct 27 22:29:24 2018 +0000
description:
Welcome tzcode-2018g
Changes to code
When generating TZif files with leap seconds, zic no longer uses a
format that trips up older 32-bit clients, fixing a bug introduced
in 2018f. (Reported by Daniel Fischer.) Also, the zic workaround
for QTBUG-53071 now also works for TZif files with leap seconds.
The translator to rearguard format now rewrites the line
"Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S" to
"Rule Japan 1948 1951 - Sep Sun>=9 1:00 0 S".
This caters to zic before 2007 and to Oracle TZUpdater 2.2.0
and earlier. (Reported by Christos Zoulas.)
Changes to documentation
tzfile.5 has new sections on interoperability issues.
diffstat:
lib/libc/time/NEWS | 35 +++++++
lib/libc/time/theory.html | 2 +-
lib/libc/time/tz-how-to.html | 14 +-
lib/libc/time/tz-link.html | 23 +++-
lib/libc/time/tzfile.5 | 198 ++++++++++++++++++++++++++++++++++++++++++-
lib/libc/time/version | 2 +-
lib/libc/time/zdump.8 | 21 ++--
lib/libc/time/zic.8 | 6 +-
lib/libc/time/zic.c | 83 +++++++++++------
9 files changed, 323 insertions(+), 61 deletions(-)
diffs (truncated from 620 to 300 lines):
diff -r 2e3edcf1c2db -r 2a4f552d4bac lib/libc/time/NEWS
--- a/lib/libc/time/NEWS Sat Oct 27 20:29:09 2018 +0000
+++ b/lib/libc/time/NEWS Sat Oct 27 22:29:24 2018 +0000
@@ -1,5 +1,40 @@
News for the tz database
+Release 2018g - 2018-10-26 22:22:45 -0700
+
+ Briefly:
+ Morocco switches to permanent +01 on 2018-10-27.
+
+ Changes to future timestamps
+
+ Morocco switches from +00/+01 to permanent +01 effective 2018-10-27,
+ so its clocks will not fall back on 2018-10-28 as previously scheduled.
+ (Thanks to Mohamed Essedik Najd and Brian Inglis.)
+
+ Changes to code
+
+ When generating TZif files with leap seconds, zic no longer uses a
+ format that trips up older 32-bit clients, fixing a bug introduced
+ in 2018f. (Reported by Daniel Fischer.) Also, the zic workaround
+ for QTBUG-53071 now also works for TZif files with leap seconds.
+
+ The translator to rearguard format now rewrites the line
+ "Rule Japan 1948 1951 - Sep Sat>=8 25:00 0 S" to
+ "Rule Japan 1948 1951 - Sep Sun>=9 1:00 0 S".
+ This caters to zic before 2007 and to Oracle TZUpdater 2.2.0
+ and earlier. (Reported by Christos Zoulas.)
+
+ Changes to past time zone abbreviations
+
+ Change HDT to HWT/HPT for WWII-era abbreviations in Hawaii.
+ This reverts to 2011h, as the abbreviation change in 2011i was
+ likely inadvertent.
+
+ Changes to documentation
+
+ tzfile.5 has new sections on interoperability issues.
+
+
Release 2018f - 2018-10-18 00:14:18 -0700
Briefly:
diff -r 2e3edcf1c2db -r 2a4f552d4bac lib/libc/time/theory.html
--- a/lib/libc/time/theory.html Sat Oct 27 20:29:09 2018 +0000
+++ b/lib/libc/time/theory.html Sat Oct 27 22:29:24 2018 +0000
@@ -407,7 +407,7 @@
EST/EDT/EWT/EPT/EDDT Eastern [North America],
EET/EEST Eastern European,
GST Guam,
- HST/HDT Hawaii,
+ HST/HDT/HWT/HPT Hawaii,
HKT/HKST Hong Kong,
IST India,
IST/GMT Irish,
diff -r 2e3edcf1c2db -r 2a4f552d4bac lib/libc/time/tz-how-to.html
--- a/lib/libc/time/tz-how-to.html Sat Oct 27 20:29:09 2018 +0000
+++ b/lib/libc/time/tz-how-to.html Sat Oct 27 22:29:24 2018 +0000
@@ -459,8 +459,8 @@
<p>An example of a specific amount of time is:</p>
<pre>
#Zone NAME GMTOFF RULES FORMAT [UNTIL]
-Zone Pacific/Honolulu ... 1933 Apr 30 2:00
- -10:30 1:00 HDT 1933 May 21 2:00
+Zone Pacific/Honolulu ... 1933 Apr 30 2:00
+ -10:30 1:00 HDT 1933 May 21 12:00
...
</pre>
@@ -559,7 +559,7 @@
Rule US 1918 1919 - Oct lastSun 2:00 0 S
Rule US 1942 only - Feb 9 2:00 1:00 W # War
Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace
-Rule US 1945 only - Sep 30 2:00 0 S
+Rule US 1945 only - Sep lastSun 2:00 0 S
</pre>
</td></tr></table></td>
</tr>
@@ -570,7 +570,7 @@
<td colspan="6" align="center"><table><tr><td>
<pre>
#Zone NAME GMTOFF RULES FORMAT [UNTIL]
-Zone Pacific/Honolulu -10:31:26 - LMT 1900 Jan 1 12:00
+Zone Pacific/Honolulu -10:31:26 - LMT 1896 Jan 13 12:00
-10:30 - HST 1933 Apr 30 2:00
-10:30 1:00 HDT 1933 May 21 2:00
-10:30 US H%sT 1947 Jun 8 2:00
@@ -598,7 +598,7 @@
<td>—</td>
<td>LMT</td>
<td>local mean time</td>
- <td>1900-01-01</td>
+ <td>1896-01-13</td>
<td>12:00</td>
</tr>
<tr align="center">
@@ -607,7 +607,7 @@
<td>HST</td>
<td>Hawaii standard time</td>
<td>1933-04-30</td>
- <td rowspan="3">02:00</td>
+ <td>02:00</td>
</tr>
<tr align="center">
<td>−9:30</td>
@@ -615,6 +615,7 @@
<td>HDT</td>
<td>Hawaii daylight time</td>
<td>1933-05-21</td>
+ <td>12:00</td>
</tr>
<tr align="center">
<td>−10:30¹</td>
@@ -622,6 +623,7 @@
<td>HST¹</td>
<td>Hawaii standard time</td>
<td>1942-02-09</td>
+ <td>02:00</td>
</tr>
<tr align="center">
<td rowspan="2">−9:30</td>
diff -r 2e3edcf1c2db -r 2a4f552d4bac lib/libc/time/tz-link.html
--- a/lib/libc/time/tz-link.html Sat Oct 27 20:29:09 2018 +0000
+++ b/lib/libc/time/tz-link.html Sat Oct 27 22:29:24 2018 +0000
@@ -524,10 +524,11 @@
under the <abbr>GPL</abbr>.</li>
<li>Microsoft Windows 8.1
and later has <code><abbr>tz</abbr></code> data and <abbr>CLDR</abbr>
-data (mentioned <a href="#CLDR">below</a>) used by
-<a href="https://en.wikipedia.org/wiki/Windows_Runtime";>Windows Runtime</a>
-classes such as <a
-href="https://msdn.microsoft.com/en-us/library/windows/apps/windows.globalization.datetimeformatting.datetimeformatter.aspx";><code>DateTimeFormatter</code></a>.
+data (mentioned <a href="#CLDR">below</a>) used by the
+<a href="https://en.wikipedia.org/wiki/Windows_Runtime";>Windows Runtime</a> /
+<a href="https://en.wikipedia.org/wiki/Universal_Windows_Platform";>Universal Windows Platform</a> classes
+<a href="https://docs.microsoft.com/uwp/api/Windows.Globalization.DateTimeFormatting.DateTimeFormatter";><code>DateTimeFormatter</code></a> and
+<a href="https://docs.microsoft.com/uwp/api/windows.globalization.calendar";><code>Calendar</code></a>.
<a id="System.TimeZoneInfo"
href="https://blogs.msdn.microsoft.com/bclteam/2007/06/07/exploring-windows-time-zones-with-system-timezoneinfo-josh-free/";>Exploring
Windows Time Zones with <code>System.TimeZoneInfo</code></a> describes
@@ -540,6 +541,8 @@
href="https://unicode.org/repos/cldr/trunk/common/supplemental/windowsZones.xml";><abbr>XML</abbr>
file</a> of the <abbr>CLDR</abbr> data maps proprietary zone IDs
to <code><abbr>tz</abbr></code> names.
+These mappings can be performed programmatically via the <a href="https://github.com/mj1856/TimeZoneConverter";>TimeZoneConverter</a> .NET library,
+or the ICU Java and C++ libraries mentioned <a href="#ICU">above</a>.
<li><a
href="https://www.oracle.com/java/index.html";>Oracle
Java</a> contains a copy of a subset of a recent
@@ -742,6 +745,14 @@
<dd>The Hydrographic and Oceanographic Service of the Chilean Navy publishes a
<a href="http://www.horaoficial.cl/historia_hora.html"; hreflang="es">history of
Chile's official time (in Spanish)</a>.</dd>
+<dt>China</dt>
+<dd>The Hong Kong Observatory maintains a
+<a href="https://www.hko.gov.hk/gts/time/Summertime.htm";>history of
+ summer time in Hong Kong</a>,
+and Macau's Meteorological and Geophysical Bureau maintains a <a
+href="http://www.smg.gov.mo/smg/geophysics/e_t_Summer%20Time.htm";>similar
+history for Macau</a>.
+Unfortunately the latter is incomplete and has errors.</dd>
<dt>Czech Republic</dt>
<dd><a href="https://kalendar.beda.cz/kdy-zacina-a-konci-letni-cas";
hreflang="cs">When daylight saving time starts and ends (in Czech)</a>
@@ -758,10 +769,6 @@
<dd>The National Institute of Metrological Research maintains a
<a href="http://oldsite.inrim.it/res/tf/ora_legale_i.shtml";>table of civil time
(in Italian)</a>.</dd>
-<dt>Macau</dt>
-<dd>The Meteorological and Geophysical Bureau maintains a
-<a href="http://www.smg.gov.mo/smg/geophysics/e_t_Summer%20Time.htm";>history
-of summer time</a>. Unfortunately it is incomplete and has errors.</dd>
<dt>Malaysia</dt>
<dd>See Singapore <a href="#Singapore">below</a>.</dd>
<dt>Mexico</dt>
diff -r 2e3edcf1c2db -r 2a4f552d4bac lib/libc/time/tzfile.5
--- a/lib/libc/time/tzfile.5 Sat Oct 27 20:29:09 2018 +0000
+++ b/lib/libc/time/tzfile.5 Sat Oct 27 22:29:24 2018 +0000
@@ -1,8 +1,8 @@
-.\" $NetBSD: tzfile.5,v 1.26 2018/10/19 23:05:35 christos Exp $
+.\" $NetBSD: tzfile.5,v 1.27 2018/10/27 22:29:24 christos Exp $
.\"
.\" This file is in the public domain, so clarified as of
.\" 1996-06-05 by Arthur David Olson (arthur_david_olson%nih.gov@localhost).
-.Dd October 19, 2018
+.Dd October 27, 2018
.Dt TZFILE 5
.Os
.Sh NAME
@@ -174,8 +174,202 @@
Second, DST is in effect all year if it starts
January 1 at 00:00 and ends December 31 at 24:00 plus the difference
between daylight saving and standard time.
+.Ss Interoperability considerations
.Pp
+Version 1 files are considered a legacy format and
+should be avoided, as they do not support transition
+times after the year 2038.
+Readers that only understand Version 1 must ignore
+any data that extends beyond the calculated end of the version
+1 data block.
+.PP
+Writers should generate a version 3 file if
+TZ string extensions are necessary to accurately
+model transition times.
+Otherwise, version 2 files should be generated.
+.Pp
+The sequence of time changes defined by the version 1
+header and data block should be a contiguous subsequence
+of the time changes defined by the version 2+ header and data
+block, and by the footer.
+This guideline helps obsolescent version 1 readers
+agree with current readers about timestamps within the
+contiguous subsequence. It also lets writers not
+supporting obsolescent readers use a
+.Dv tzh_timecnt
+of zero
+in the version 1 data block to save space.
+.Pp
+Time zone designations should consist of at least three (3)
+and no more than six (6) ASCII characters from the set of
+alphanumerics,
+.Dq \&- ,
+and
+.Dq + .
+This is for compatibility with POSIX requirements for
+time zone abbreviations.
+.Pp
+When reading a version 2 or 3 file, readers
+should ignore the version 1 header and data block except for
+the purpose of skipping over them.
+.Pp
+Readers should calculate the total lengths of the
+headers and data blocks and check that they all fit within
+the actual file size, as part of a validity check for the file.
+.Ss Common interoperability issues
+This section documents common problems in reading or writing TZif files.
+Most of these are problems in generating TZif files for use by
+older readers.
+The goals of this section are:
+.Bl -bullet
+.It
+to help TZif writers output files that avoid common
+pitfalls in older or buggy TZif readers,
+.It
+to help TZif readers avoid common pitfalls when reading
+files generated by future TZif writers, and
+.It
+to help any future specification authors see what sort of
+problems arise when the TZif format is changed.
+.El
+.Pp
++When new versions of the TZif format have been defined, a
+design goal has been that a reader can successfully use a TZif
+file even if the file is of a later TZif version than what the
+reader was designed for.
+When complete compatibility was not achieved, an attempt was
+made to limit glitches to rarely-used timestamps, and to allow
+simple partial workarounds in writers designed to generate
+new-version data useful even for older-version readers.
+This section attempts to document these compatibility issues and
+workarounds, as well as to document other common bugs in
+readers.
+.Pp
+Interoperability problems with TZif include the following:
+.Bl -bullet
+.It
+Some readers examine only version 1 data.
+As a partial workaround, a writer can output as much version 1
+data as possible.
+However, a reader should ignore version 1 data, and should use
+version 2+ data even if the reader's native timestamps have only
+32 bits.
+.It
+Some readers designed for version 2 might mishandle
+timestamps after a version 3 file's last transition, because
+they cannot parse extensions to POSIX in the TZ-like string.
+As a partial workaround, a writer can output more transitions
+than necessary, so that only far-future timestamps are
+mishandled by version 2 readers.
+.It
+Some readers designed for version 2 do not support
+permanent daylight saving time, e.g., a TZ string
+.Dq EST5EDT,0/0,J365/25
+denoting permanent Eastern Daylight Time (\&-04).
+As a partial workaround, a writer can substitute standard time
+for the next time zone east, e.g.,
+.Dq AST4
++for permanent Atlantic Standard Time (\&-04).
+.It
+Some readers ignore the footer, and instead predict future
+timestamps from the time type of the last transition.
+As a partial workaround, a writer can output more transitions
+than necessary.
+.It
+Some readers do not use time type 0 for timestamps before
+the first transition, in that they infer a time type using a
+heuristic that does not always select time type 0.
+As a partial workaround, a writer can output a dummy (no-op)
Home |
Main Index |
Thread Index |
Old Index