summaryrefslogtreecommitdiff
path: root/data/README.timezones
diff options
context:
space:
mode:
authorPerberos <[email protected]>2011-12-01 21:42:39 -0300
committerPerberos <[email protected]>2011-12-01 21:42:39 -0300
commitfe8aea1c3b5348347633da18a02b0bffd3b266a1 (patch)
tree9881bf77df7572844707cc7c50bd8ca6b5a97076 /data/README.timezones
downloadlibmateweather-fe8aea1c3b5348347633da18a02b0bffd3b266a1.tar.bz2
libmateweather-fe8aea1c3b5348347633da18a02b0bffd3b266a1.tar.xz
moving from https://github.com/perberos/mate-desktop-environment
Diffstat (limited to 'data/README.timezones')
-rw-r--r--data/README.timezones47
1 files changed, 47 insertions, 0 deletions
diff --git a/data/README.timezones b/data/README.timezones
new file mode 100644
index 0000000..8f82bac
--- /dev/null
+++ b/data/README.timezones
@@ -0,0 +1,47 @@
+Notes on assigning <tz-hint>s
+-----------------------------
+
+The <tz-hint> field in Locations.xml.in is used by the clock applet to
+guess the correct time zone that goes with a particular location. As
+the tag name suggests, it is just a hint; the user is allowed to
+override it if the applet guesses wrong. Still, it is nice to have
+them be as close to correct as possible.
+
+
+The timezone names come from the tzdata database; you should have a
+complete list of the current timezones names in
+/usr/share/zoneinfo/zone.tab. If you are going to be figuring out the
+timezones for a region, it may also be useful to grab the source data
+from ftp://elsie.nci.nih.gov/pub/. (The "tzdataXXXXX.tar.gz" file)
+
+
+The most important thing to realize about tzdata is that it has a
+separate time zone name for every region that has had its own distinct
+timezone rules *at any point since 1970* (the start of UNIX time_t).
+This means that many of the timezones listed are no longer in use and
+can mostly be ignored. Eg, zone.tab lists 11 timezones for Argentina,
+even though as of 2008 all of Argentina is in the same timezone.
+
+In the cases where tzdata has more timezones for a country than the
+government of that country recognizes, Locations.xml.in tries to pick
+one tzdata timezone to correspond to each government-defined timezone,
+and uses those timezones throughout the country rather than using the
+historically-more-specific ones. (This will make it easier to localize
+the names of the timezones in the future.) So, eg, in the mainland
+United States, the four official timezones (Eastern, Central,
+Mountain, and Pacific) are mapped to "America/New_York",
+"America/Chicago", "America/Denver", and "America/Los_Angeles",
+respectively. Regions that have switched from one timezone to another
+in the past (such as parts of Kentucky and Indiana) are simply listed
+according to whichever timezone they are *currently* in, rather than
+picking an appropriate "micro-timezone" such as
+"America/Indiana/Indianapolis".
+
+
+Finally, the names of timezones will occasionally change between
+releases of tzdata. (Eg, "Asia/Calcutta" was recently renamed to
+"Asia/Kolkata" to match the new preferred spelling of that city.)
+Locations.xml.in should always use the most recent names, because
+distros should always be shipping the most recent tzdata, to ensure
+that the daylight-savings-time rules for different countries match the
+latest government decrees.