>From b228f9861e3276b112b2d34600e7a52d0b52453a Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Tue, 19 Feb 2019 11:57:27 -0800
Subject: [PROPOSED] Mention timezone splits and identifiers

* theory.html (Timezone identifiers): Rename from "Names of timezones".
(Interface stability): Mention timezone splits.
---
 theory.html | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/theory.html b/theory.html
index 8f079b9..38681fc 100644
--- a/theory.html
+++ b/theory.html
@@ -107,9 +107,9 @@ It does not always make sense to talk about a timezone's
 </section>
 
 <section>
-  <h2 id="naming">Names of timezones</h2>
+  <h2 id="naming">Timezone identifiers</h2>
 <p>
-Each timezone has a unique name.
+Each timezone has a name that uniquely identifies the timezone.
 Inexperienced users are not expected to select these names unaided.
 Distributors should provide documentation and/or a simple selection
 interface that explains each name via a map or via descriptive text like
@@ -1221,6 +1221,17 @@ For example, users should not rely on particular <abbr>UT</abbr>
 offsets or abbreviations for timestamps, as data entries are often
 based on guesswork and these guesses may be corrected or improved.
 </p>
+
+<p>
+Timezone boundaries are not part of the stable interface.
+For example, even though the <samp>Asia/Bangkok</samp> timezone
+currently includes Chang Mai, Hanoi, and Phnom Penh, this is not part
+of the stable interface and the timezone can split at any time.
+If a calendar application records a future event in some location other
+than Bangkok by putting "<samp>Asia/Bangkok</samp>" in the event's record,
+the application should be robust in the presence of timezone splits
+between now and the future time.
+</p>
 </section>
 
 <section>
-- 
2.20.1