- tz - lists.iana.org

tz abbreviations / zdump for programmers
by Boruch Baum June 19, 2012

June 19, 2012

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings y'all, I have a bit of a long (inaugural) post here to describe my interest in joining this list, and what I might be able to contribute to the greater glory of tz-correctness. BTW, as part of my 'due diligence' before posting this, I read/scanned a selection of the collection of detailed comments in the glibc-2.13/timezone files, as well as the timezone entry in glibc-2.13/FAQ. I'm very glad those comments are there. CONTENTS ======== 1] The app/library I develop/maintain 2] End users' stubborn insistence on using tz abbreviations 2.1] zone.tab modification proposal 2.2] zone.abbr.tab proposal 3] The 'zdump' programmer's function I 'need' to write 1] The app/library I develop/maintain ===================================== libhdate is a FOSS collection for Hebrew time/date 'stuff', for which time zone data and location coordinates are important because: 1) we have about a dozen significant astronomical times-of-day that need to be mapped to a correct local clock time at any particular location; 2) users want that information for future and past dates, and; 3) users want that information for locations in other parts of the globe. This FOSS collection is under active development and versions are available from sourceforge and the Debian GNU/Linux repositories. There are unrelated, closed-source, alternatives available (eg. kaluach for windows and java, and dostagfarlinux for, um, linux). 2] End users' stubborn insistence on using tz abbreviations =========================================================== ... and who can blame them, when that's all they hear in the media. This leaves me in a bind, because if I accept a tz abbreviation as a user input, I have two undesirable options: 1) I could scan ALL the ~420 tzif files for matches and, if I discover that the tz abbrev is not unique, either make an educated guess (based upon the user's locale definition which often will include a country code and a language) or prompt the user for clarification; or 2) I could pre-compile a list that suits my parochial needs, and update my list anytime the tzdata package is updated (and still have to occassionally guess or prompt the user). Then I said to myself, "self, you can't be the only one out there facing these users - go consult and find a global solution". Following are two proposals. Neither may be perfect, but each may make life alot easier for many... 2.1] zone.tab modification proposal =================================== Add a new column/field to this file, in the format: {{;xxx:nnnnn;xxx:nnnnn;...;}} where: xxx is a tz abbreviation nnnnn is the UTC offset for that abbreviation. The use of ";", ":", and braces are to simplify the task of parsing the data programmatically. Advantages: 1) All information for a timezone on a single line (ie. in a single record). 2) All worldwide information in a single file (no need to travel the dir-tree and parse ~420 files) Disadvantages: 1) Long line(record) length 2) Messing with the format of an existing file, upon which others may depend 3) Requires change to whatever script/program is used to compile the file for release 2.2] zone.abbr.tab proposal =========================== Create a new text file, say /usr/share/zoneinfo/zone.abbr.tab, sorted by tz abbreviation, with a format like: tz_abbrev country_code localedef useful for setting $LC_TIME and for language matching is_dst if yes, this would have the abbreviation of the non_dst version of this tz. utc_offset historical_only (y/n) - ie. whether currently in use. full_name of the abbreviation, not of the 'real' tz name. Advantages: 1) Easy to find matches for users' pesky (short and convenient-to-type) tz_abbr 2) All worldwide information in a single file (no need to travel the dir-tree and parse ~420 files) 3) Includes additional useful information (is_dst, historical_only, full_name, locale_def) 4) Doesn't mess with existing files Disadvantages: 1) It's a new file. 2) Requires new script/program to compile the file for release 3] The 'zdump' programmer's functiion I 'need' to write ======================================================= This section isn't directly related to the above. I don't NEED to write a 'zdump' programmer's functiion; I WANT to, because I remember when a 4Mhz clock speed was wicked fast, and using the current glibc time functions for my libhdate collection would be tremendously wasteful, although today's users will probably never notice. For this section, the reason I want to consult with members of this list (and I appreciate you having read this far) is to make the function as universally useful as possible (it will be FOSS/GPL3+) . My current plan is: int zdump( /// returns TRUE on success, FALSE on failure const char* tzname, /// fully-qualified time-zone name /// (eg. Asia/Baku) const time_t start, /// seconds from epoch to be scanned const time_t end, /// seconds from epoch to be scanned int* num_entries, /// upon successful return, int will contain /// the number of dst transitions + 1, /// for the interval 'start' to 'end'. /// The first entry will always be the /// tz state at time_t start. /// Returns 0 on failure. void* return_data /// upon successful return, will contain a pointer to a malloc()ed space of /// 'num_entries' of 'tzinfo' data, as /// described below, sorted in ascending /// chronological order. /// Returns NULL on failure. ) tzinfo { time_t start /// seconds from epoch int utc_offset /// in minutes, or maybe seconds. char is_dst /// 0/1 char[] tz_abbrev /// const char end_mark /// '\0' } - -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJPzM3HAAoJEDvrUfDmCx9LbJ4P/RMD+8KWkXxrLtpivyQVz6Yv h88mWjwfeTpb7laT4yeg726YYUQEDfhueLFELRTpxR6aAIAW7fBZEu6UwEMSsxHe UaQdx/xc/03aei/AG6z31u0C+arA40qs8twxEw5pdyHfvBxhQh0YOxO+dl01+zmg w4Y+Mlyd72QmAZ+pdIc5l2L/nTh9L+YnlmPxsXoomYSTh+9kigOxS5JZVMu2sYy6 7FGMj+mybrtru12qwJmoFG2hNjVgy0zKSuJ1HOXmqi5JKBNthlsfkyV4E9vzSGWC PkkbI8R0adGnqKa9faHQxFG+jV+K5Fjscr3eabBi8IYHG+cGYOL6vD0KkNFbHRQf wLRGpkkMjoJm9cxJ7f17wcQFtYFKjcDLIqqtDuT7LhHJ7iF2x4lTqd4YjvpA6rqN fcD+4TNfm8Na5bNbKNJqvWy+Od46wSNqFOiUf9NQaWsUZx/yiXjw1Sl4Jqi7/2Sg A3rc2bcw02Co80bWA+lsMbZUL5NJlQAdfWCKe7xafdILX8PPbe0CaTHzNUFd4vR9 70AJsq6teBivVHossldNlQfsK+S4HmcSMGPt1AuANjGUv0ZoCveR71Ewt0D2wbi4 hSEaSI/P3MVSsFRMJZIoMXlFTuF6d6qItoRvmHrLdU2u5f1+Kjbt7tH0eMOrcdm9 BUi/N3QtrJkU6vWXjLal =n4Kd -----END PGP SIGNATURE-----

16 30

Re: [tz] Are these valid timezone definitions?
by Tadashi Abe June 15, 2012

June 15, 2012

Hi, sorry to interrupt with newbie question. david singleton wrote: >When I define a timezone with export >TZ="NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0" >there is no change in time when daylight savings ends. > >Is this a known problem? Or a problem with how the timezones are defined? Now I'm testing DST start/end by setting the actual system clock as same as the above method and get the same issue. 1. export TZ="NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0" 2. set system clock just 5 seconds prior to DST [start|end] 3. 5 seconds later, check if switch between DST and STD occurs, but not. As the comment from Zefram, it works when I check date with -d option. http://mm.icann.org/pipermail/tz/2012-June/018059.html >It's always difficult to test timezone offset issues when you're >stating the test times in local time. By the way, your testing method >of modifying the system clock is problematic. It's much better to use >the -d option of GNU date to display a particular time without touching >the clock. Why doesn't it work well when I try to test by modifying the actual system clock? -- Tadashi Abe

3 2

Re: [tz] Patch - America/Los_Angeles zone comment
by Steve Jones June 14, 2012

June 14, 2012

At 13:30 6/9/2012, OvV_HN wrote: >Regarding Malheur county in Oregon: you could add: the _northern_ >part of Malheur county. Here is an image that reflects the borders of Malheur county as well as the time zone border in the area: <http://ontimezone.com/images/malheur.gif>http://OnTimeZone.com/images/malheur.gif The portion of the time zone border that bisects Malhuer county starts on the western border of the county at the southwest corner of T. 35 S., R. 37 E., and runs due east to the eastern border of the county. There is no obvious manmade, political, or geographic feature that further reflects or indicates that portion of the time zone border. Cheers, Steve Jones OnTimeZone.com

3 2

Another Newbie question
by Donald MacQueen June 12, 2012

June 12, 2012

The background is that I have added timezone support to our multi-platform application. To test our app on Windows, I used zoneinfo copied from a Fedora distribution, and I have 143 units tests that test time zones like 'right/America/Detroit', 'posix/America/Detroit', 'US/Eastern', and 'America/Detroit'. But when I run 'for f in *; do zic -d someOutputDir $f;done' on the latest data from iana.org, I get 'America/Detroit' but not 'right/America/Detroit', 'posix/America/Detroit', or 'US/Eastern'. How come? How are they generated on Linux OS's? Thanks -- Donald [|] A bad day in [] is better than a good day in {}

2 1

Patch - America/Los_Angeles zone comment
by OvV_HN June 9, 2012

June 9, 2012

In reply to: [tz] Patch - America/Los_Angeles zone comment Alan Mintz Alan_Mintz+TZ_IANA at Earthlink.net Fri Jun 8 21:27:24 UTC 2012 .... Alternatively, more accuracy could be provided by the following changes: < northamerica > northamerica.new 395,397c395,398 < # Idaho, Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, < # and the northern three-quarters of Idaho county), < # most of Nevada, most of Oregon, and Washington --- > # Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, > # the towns of Burgdorf and Warren, and the part of Idaho county > # lying north of the Salmon River), Nevada (except for West Wendover) > # Oregon (except for part of Malheur County), and Washington REPLY: This confuses me. I believe that the state of Idaho has a county named Idaho with a Salmon River running through it. The federal timezone law stipulates that south of this river Mountain Time is in effect, north of it Pacific Time. There are only a couple of places in the southern part of Idaho county, and Burgdorf and Warren are indeed two of them. Why don't we stay with the legal description, stating north/south of Salmon River? Regarding Malheur county in Oregon: you could add: the _northern_ part of Malheur county. Oscar van Vlijmen

1 0

Idea for internationalized time point unique time zone abbreviations
by Tobias Conradi June 8, 2012

June 8, 2012

== INTRODUCTION == If time zone abbreviations for a given point in time are unique they can be used to faster find IANA time zones. The current abbreviations are not unique, e.g. IST could stand for Indian Standard Time and for Israel Standard Time. Since the IANA time zone database cutoff point is 1970-01-01T00:00:00Z and the first publication of ISO 3166 alpha-2 country codes occurred in the early 1970s, one could easily use the country codes to separate sets of abbreviations between countries. One rule sometimes used in the IANA time zone database for creating new abbreviations is to use the ISO alpha-2 country codes. The idea presented here applies such a rule rigidly. Apart from that the idea presented also applies rigid rules for marcation of offset changes like daylight saving time. == Features == One can derive the country of the time zone to which the abbreviation belongs from the abbreviation and from knowledge of the current ISO country code for that country. This is not possible with current IANA time zone database abbreviations like CET, IST, EDT, GALT, EAST, CT (e.g. Cuba Time), CUT (1924 Central Ukraine Time). One can group the abbreviations by country, alone by alphabetic sorting of the abbreviations. This is not possible with current IANA time zone database abbreviations like CST (US), CT (Cuba), PST (US). If the year is known, one can identify the time zone for any given abbreviation. This is not possible with current IANA time zone database abbreviations like IST. Reduces the number of IANA time zones for some abbreviations, e.g. IST is used for Asia/Jerusalem, Asia/Kolkata, while INCT/INZT would only refer to Asia/Kolkata. == DEFINITIONS == === D0) General === D0.1) DST - Daylight saving time D0.2) Format: "<CC><LC><(OC)>T" #abbreviations would be four or five letters long. Details in D1 to D4. === D1) CC - country code and similar === - ISO alpha-2 country code or, - a special code like "EU" or, - a code from the private use area to define larger regions, e.g.: -- XA - ASEAN -- XE - "East" for UTC offsets zones having positive offset -- XW - "West" for UTC offsets zones having negative offset -- ZZ - the whole world, used for UTC and UTC offset zones, details see examples. === D2) LC - location code and similar === D2.1) A character from the set [A-Z], unique for each real time zone within the country. Preferably not from the set [SDF] or any letter agreed in D3 for offset changes D2.2) A character from the set [0-9] for numbered zones, e.g. in Russia. D2.3) The letter C (Common Time) for the most common time, maybe also N derived from "National Time". D2.4) The letter Z could be used if there is only one time zone. Could be dropped for countries that only have one zone, but mandatory per D0.2). D2.5) For UTC offset zones that start with ZZ, when using date-time group (DTG) letters, the letter G - not the letter L to make changing into or from E harder. Otherwise either E for East or W for West, as defined in D1. === D3) OC - seasonal offset code and similar === D3.1) for DST a letter from the set [SD], preferably "D" since "S" in some contexts stands for "standard time" So even if in Europe the term "summer time" is more common, the preferred presentation uses unambiguous"D" D3.2) For wartime maybe the letter W or F as in forward time, W in D2 stands for West. D3.3) For double summer time - to be defined, maybe M for midsummer time D3.4) For absence of any extra rules "standard time", the letter Z is optional. D3.5) For UTC offset zones: a digit. === D4) T === As currently done in English to indicate "Time". == EXAMPLES == === E1) No DST === CUCT - Cuba (Common) Time#in IANA tzdb northamerica 8.54 is CT THCT - Thailand (Common) Time USET - US Eastern Time USCT - US Central Time USPT - US Pacific Time CAET - Canada Eastern Time CLCT - Chile (Common) Time #Continental Time CLET - Chile Eastern Time #Easter Islands, which in the IANA tzdb is EAS%sT ECCT - Ecuador (Common) Time #Continental Time ECGT - Galapagos Time #which in the IANA tzdb is GALT RUOT - Omsk Time #in IANA tzdb is OMST, could be read as Oman Summer/Standard Time RUMT - Moscow Time #Maybe RUCT - Russia Central/Common Time or RUNT - Russia National Time RUKT - Kaliningrad Time RUIT - Irkutsk Time RUVT - Volgograd Time #in IANA tzdb was VOLT Optional: RU1T - Russia First Time Zone Optional: RU2T - Russia Second Time Zone EUCT - Central European Time #Some countries that use this time, are not in the EU. EUWT - Western European Time #See comment for EUCT EUET - Eastern European Time #See comment for EUCT XACT - ASEAN Common Time XE01T - UTC+01 XE08T - UTC+08 XE13T - UTC+13 XW06T - UTC-06 XW11T - UTC-11 ZZZT - UTC ZZE1T - UTC+01 ZZE8T - UTC+08 ZZEAT - UTC+10 # A = hexadecimal for 10 ZZEDT - UTC+13 # A = hexadecimal for 13 ZZW6T - UTC-06 ZZWBT - UTC-11 # B = hexadecimal for 11 #Letters from the NATO(?) date-time group #taken from http://de.wikipedia.org/wiki/Date_Time_Group ZZGZT - UTC±00 ZZGAT - UTC+01 ZZGHT - UTC+08 ZZGKT - UTC+10 ZZGST - UTC-06 ZZGXT - UTC-11 === E2) With DST === #for meaning of the third letter see section E2 USEDT USCDT USPDT CAEDT RUMDT # Daylight saving time or "decree time" EUCDT #preferred as defined in D3.1 -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

13 35

Patch - America/Los_Angeles zone comment
by Alan Mintz June 8, 2012

June 8, 2012

I'd like to try this once more without it getting buried or expanded into other issues, please. As it's written, the America/Los_Angeles comment in northamerica v8.54 in tzdata release 2012c does not make sense. The simple solution is to remove 7 characters from line 395: < northamerica > northamerica.new 395c395 < # Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, --- > # Idaho, Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, Alternatively, more accuracy could be provided by the following changes: < northamerica > northamerica.new 395,397c395,398 < # Idaho, Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, < # and the northern three-quarters of Idaho county), < # most of Nevada, most of Oregon, and Washington --- > # Kootenai, Latah, Lewis, Nez Perce, and Shoshone counties, > # the towns of Burgdorf and Warren, and the part of Idaho county > # lying north of the Salmon River), Nevada (except for West Wendover) > # Oregon (except for part of Malheur County), and Washington AFAIK, this description is completely accurate (though it doesn't reflect unofficial observances in Nevada, which I assume wouldn't be appropriate here).

1 0

Indonesia - A government committee is proposing a single time zone
by Tobias Conradi June 7, 2012

June 7, 2012

http://www.thejakartapost.com/news/2012/05/26/single-time-zone-may-begin-la… -- Tobias Conradi Rheinsberger Str. 18 10115 Berlin Germany http://tobiasconradi.com/

4 4

may be a small mistake in the localtime.c code
by Z V June 6, 2012

June 6, 2012

Hello, The next piece of code looks like a mistake: localtime.c (1477-1484) while (i > 0 && sp->lsis[i].ls_trans == *sp->lsis[i - 1].ls_trans + 1* && sp->lsis[i].ls_corr == sp->lsis[i - 1].ls_corr + 1) { ++hit; --i; } As far as I understand here are processed 'Leap' rules with '++' correction. If so, sp->lsis[i].ls_trans must be equal to sp->lsis[i - 1].ls_trans. BR, Igor

3 2

Are these valid timezone definitions?
by david singleton June 6, 2012

June 6, 2012

I posted a question earlier about a problem with exporting TZ, which was caused by a typo in the timezone man page on my ubuntu 10.10 system. When the typo was fixed the daylight savings end worked correctly. I've been given a new test in which one case seem to show a problem of when daylight savings starts, and one case when daylight savings ends. When a timezone is defined as : export TZ="NZST-23:00:00NZDT-24:00:00,M10.1.0,M3.3.0" the time is set one hour ahead when daylight savings begins. When I define a timezone with export TZ="NZST-12:00:00NZDT-13:00:00,M10.1.0,M3.3.0" there is no change in time when daylight savings ends. Is this a known problem? Or a problem with how the timezones are defined? I'll attach the test case. thanks Dave

3 2