Add note on -00:00 as offset suffix and UTC-00:00 as zone

The former is overtly forbidden by ISO 8601 but should be recognized
due to RFC 3339's use of it. The "Serialising Extended Data About
Times and Events Working Group" (sedate WG) has established how to
resolve this, so document that conclusion and note the consequent
inadvisability of using UTC-00:00 as a zone ID (although it should
still be accepted).

Change-Id: Ib9fbbe6765117bfa9a84e726d0e75f7397a4c813
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>

util/locale_database/cldr2qtimezone.py

@@ -193,7 +193,7 @@ utcIdList = (
     ('UTC-03:00', -10800),
     ('UTC-02:00',  -7200),
     ('UTC-01:00',  -3600),
-    ('UTC-00:00',      0),
+    ('UTC-00:00',      0), # Should recognize, but avoid using (see Note below).
     ('UTC+00:00',      0),
     ('UTC+01:00',   3600),
     ('UTC+02:00',   7200),
@@ -220,6 +220,17 @@ utcIdList = (
 
 ### End of data that may need updates in response to CLDR ###
 
+# Note: -00:00 (without the UTC prefix) was introduced in RFC3339 as a
+# way to indicate that a date-time has been converted to UTC but its
+# use should not be understood to say anything about the local time of
+# the origin of the message using it. However, ISO 8601 has, since
+# 2000, forbidden this as an offset suffix. The more recent compromise
+# is to use Z to convey the meaning RFC3339 gave to -00:00. So the use
+# of -00:00 as offset suffix should be avoided (and, by extension,
+# likewise for UTC-00:00 as a zone ID), but this suffix (and ID)
+# should be recognized when consuming data generated by other sources,
+# for backwards compatibility.
+
 class ByteArrayData:
     def __init__(self):
         self.data = []