- tz - lists.iana.org

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

Re: [tz] FW: may be a small mistake in the localtime.c code
by Arthur David Olson June 6, 2012

June 6, 2012

For (so far unused in the real word) double leap seconds, the binary file has different values for successive ls_trans/ls_corr pairs. For example, if the current "leapseconds" is changed so that the upcoming leapsecond is a double, a la... Leap 2012 Jun 30 23:59:60 ++ S ...then there will be an an entry with an ls_trans value of 1341100824 and an ls_corr value of 25 followed by an entry with an ls_trans value of 1341100825 and an ls_corr value of 26. Bottom line: Bradley White's code should be okay. --ado ________________________________________ From: Z V [igt31415926(a)gmail.com] Sent: Thursday, May 24, 2012 6:02 AM To: tz(a)iana.org Subject: [tz] may be a small mistake in the localtime.c code 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

1 0