tzdata/backport-Improve-heads-up-advice.patch

46 lines
1.9 KiB
Diff
Raw Normal View History

2020-10-10 19:03:29 +08:00
From 241e6df0731f0e8d2a07a7ac42878f00086bd642 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Thu, 10 Sep 2020 17:48:59 -0700
Subject: [PATCH 32/47] Improve heads-up advice
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* tz-link.html (Changes to the tz database): Clarify that
an official announcement should be made a year before
changes affect clocks, and that its OK to give more than
a years notice. From suggestions by Florian Weimer
and Robert Elz.
---
tz-link.html | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/tz-link.html b/tz-link.html
index dfdaece..e6e4acd 100644
--- a/tz-link.html
+++ b/tz-link.html
@@ -215,13 +215,18 @@ generated <a href="https://github.com/timparenti/tzdata-meta">automatically</a>.
If your government plans to change its time zone boundaries or
daylight saving rules, inform <code>tz@iana.org</code> well in
advance, as this will coordinate updates to many cell phones,
-computers, and other devices around the world. With
-less than a year's notice there is a good chance that some
+computers, and other devices around the world.
+The change should be officially announced at least a year before it affects
+how clocks operate; otherwise, there is a good chance that some
computer-based clocks will operate incorrectly after the change, due
to delays in propagating updates to software and data. The shorter
the notice, the more likely clock problems will arise; see "<a
href="https://codeofmatt.com/2016/04/23/on-the-timing-of-time-zone-changes/">On
the Timing of Time Zone Changes</a>" for examples.
+The <code><abbr>tz</abbr></code> data can represent planned changes
+far into the future, and a long-planned change can easily be reverted
+or otherwise altered with a year's notice before the change would have
+affected clocks.
</p>
<p>
Changes to the <code><abbr>tz</abbr></code> code and data are often
--
1.8.3.1