- tz - lists.iana.org

Revisiting Australian time zone abbreviations
by Richard Stanway June 13, 2010

June 13, 2010

Hello, I came across this mailing list while researching a time zone issue on our website which indirectly makes use of the zoneinfo. We localize some timestamps to the visitors time zone, but the site is trafficked by a predominately US audience where the abbreviation "EST" is used quite often. It is difficult for an Australian visitor to realize that the times they are seeing have been localized since they show for example as "8pm EST" due to the abbreviations used for the Australian time zones, leading to confusion as to whether it is US EST or AU EST. The last discussion on AEST vs EST seems to be about 9 years old and I figured it was time to revisit the subject now that there seems to be an official source. The government website of Australia states the time zone names for Australia are Australian Eastern Standard Time (AEST), Australian Central Standard Time (ACST) and Australian Western Standard Time (AWST) with Australian Eastern Daylight Time (AEDT) and Australian Central Daylight Time (ACDT) when observing daylight saving time. Reference: http://australia.gov.au/about-australia/our-country/time Any chance of these official names making it into a zoneinfo update?

1 0

Patches for zic.8 manpage
by Ulrich Spörlein June 9, 2010

June 9, 2010

Hello, not sure if this is the right list to submit "code" changes to, but as I'm working on getting the FreeBSD manpage corpus into shape for mandoc/mdocml, there's a patch I'd like you to commit. The patch fixes some missing quotes. Regards, Uli

1 0

FW: Timezone option
by Olson, Arthur David (NIH/NCI) [E] May 25, 2010

May 25, 2010

I'm forwarding this message from Honey Bajaj, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. (On some systems, setting TZ to "GMT-48" may do what HB wants.) --ado From: honey bajaj [mailto:honeybajaj1@rediffmail.com] Sent: Tuesday, May 25, 2010 3:36 To: tz(a)lecserver.nci.nih.gov Subject: Timezone option Hi, I have a testing requirement which needs to alter the system date to a couple of days ahead of current date. I am wondering if its possible to have a custom timezone which can provide this date change ability to drift the current time to couple of days ahead by setting the TZ environment variable. Regards,

4 3

Russian time zone issue reported
by Gary Lasker May 25, 2010

May 25, 2010

Hello! I've been getting started maintaining tzdata for Ubuntu, and I wanted to check in with the list regarding an issue reported by an Ubuntu user in the following bug report (please refer to comment #16 posted by Guria: https://bugs.launchpad.net/ubuntu/lucid/+source/tzdata/+bug/540295 The comment from Guria is as follows: "Just looked at timezones more precisely. Unfortunately changes are wrong. In changed tz's was set only summer time, but winter time stays unchanged. This timezones doesn't exists already in fact. Europe/Samara is now exactly equal Europe/Moscow, Asia/Kamchatka is Asia/Magadan. Follow next link for details: http://wwp.greenwichmeantime.com/time-zone/russia/time-zones/index.htm Also, please don't forget to provide this info to upstream or other distributions." I'd appreciate it very much if somebody could review this statement to determine what, if any, action may be required. Thank you very much and please email me if there's anything further I can provide. I'll be following responses on-list. Thanks again and best regards, Gary Lasker

3 2

Information Requeté
by Maameri, Adraa May 18, 2010

May 18, 2010

Hello, As you know, there are some countries that change their time zone randomly in the year. We have Egyptian users that want to know if it is possible to create another time zone called Cairo (+3:00). They will change manually their time zones and the best point is that the time of their meetings won't be shifted. Do you think it is possible to do ? Thanks in advance for your response. Regards, </PRE><p style="font-family:arial;color:grey" style="font-size:13px">This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.</p><PRE>

1 0

Xinjiang Time
by Luther Ma May 15, 2010

May 15, 2010

With the restoration of internet to Xinjiang yesterday after a ten month hiatus, I would like to make one more plea for Xinjiang Time to be included in the tz database. (Last year we discussed Xinjiang Time, a semi-official time used primarily by minority ethnic groups in the Xinjiang Uyghur Autonomous Region of China, as well as in some official Xinjiang Chinese language publications.) Although any proposal is better than nothing at this point, I've summarized here my preferences and my reasons. 1. That the locations be the already existing Urumqi/Asia and Kashgar/ Asia. These already exist in the database and have been the most common English spelling on the Internet and on maps for some time. (These names correspond closely to the Uyghur pronunciation and are probably more commonly used because of the autonomous region status of the area. The "q" in Urumqi is pronounced like the "ch' in English.) 2. That the name of the time zone be called Xinjiang Time, abbreviated XJT. This nomenclature corresponds word for word with the most common usage in Chinese and Uyghur, as well as all references to it I can find in English. It would therefore be immediately recognizable by users of Xinjiang Time. This would also agree with the recommendations in the Theory file. > If there is no common English abbreviation, abbreviate the English > translation of the usual phrase used by native speakers. URUT for Urumqi Time would be another possibility as it is a recognized, perhaps more official term, but not nearly as widely used. 3. That no other location be added (especially with the same latitude and longitude) to accommodate the use of Beijing Time (also widely used in Xinjiang, esp. by close to 100% of the ethnic Han population). The reason for this is two-fold. a. It agrees with the recommendations in Theory, Urumqi being quite a bit smaller than Beijing > Use the most populous among locations in a country's time zone, > e.g. prefer `Shanghai' to `Beijing' and by definition is redundant. > If all the clocks in a country's region have agreed since 1970, > don't bother to include more than one location b. But perhaps more critically, it is an added difficulty to implement two zones having the same position on most GUI's. I am afraid that GUI developers would choose the more commonly used time and that Xinjiang time, although present in the tzdata would be swallowed up in the user interface. 4. And lastly, that no effort be made to link the time zone with summer time changes that happened in the rest of the country during the late eighties, as the local populace, at least to some extent, continued to use standard time. If it is, however, desirable to have a summer time, I believe the abbreviation XJST would most closely follow the recommendations of the Theory file So these, then, are my suggestions and the reasons why. Thanks for taking another look into this, -Luther PS I have been patching the tzdata for my own use as well as for a very small distribution, which I have pasted below in case it is of any use to others or in changing the official version. $ diff -c tzdata2010j/asia proposedXJT/asia *** tzdata2010j/asia 2010-05-10 21:07:27.000000000 +0800 --- proposed XJT/asia 2010-05-15 19:08:24.000000000 +0800 *************** *** 390,396 **** # Fukang, Kuitun, Kumukuli, Miquan, Qitai, and Turfan. Zone Asia/Urumqi 5:50:20 - LMT 1928 # or Urumchi 6:00 - URUT 1980 May # Urumqi Time ! 8:00 PRC C%sT # Kunlun Time # West Tibet, including Pulan, Aheqi, Shufu, Shule; # West Xinjiang, including Aksu, Atushi, Yining, Hetian, Cele, Luopu, Nileke, --- 390,396 ---- # Fukang, Kuitun, Kumukuli, Miquan, Qitai, and Turfan. Zone Asia/Urumqi 5:50:20 - LMT 1928 # or Urumchi 6:00 - URUT 1980 May # Urumqi Time ! 6:00 - XJT # Kunlun Time # West Tibet, including Pulan, Aheqi, Shufu, Shule; # West Xinjiang, including Aksu, Atushi, Yining, Hetian, Cele, Luopu, Nileke, *************** *** 462,468 **** Zone Asia/Kashgar 5:03:56 - LMT 1928 # or Kashi or Kaxgar 5:30 - KAST 1940 # Kashgar Time 5:00 - KAST 1980 May ! 8:00 PRC C%sT # From Lee Yiu Chung (2009-10-24): --- 462,468 ---- Zone Asia/Kashgar 5:03:56 - LMT 1928 # or Kashi or Kaxgar 5:30 - KAST 1940 # Kashgar Time 5:00 - KAST 1980 May ! 6:00 - XJT # From Lee Yiu Chung (2009-10-24):

1 0

gmtime() oddities for large values
by Edwin Groothuis May 13, 2010

May 13, 2010

Hello! With my hat of the tzdata/tzcode maintainer on the FreeBSD system, I sometimes get the more interesting bugs reported. For example this piece of code, on 64 bit machines it returns the same values for values bigger than the initial one: #include <errno.h> #include <stdint.h> #include <stdio.h> #include <time.h> void t_inspect(time_t t) { struct tm *tp; errno = 0; tp = gmtime(&t); printf("t: %ld, tp: %p errno: %d\n", t, tp, errno); if (tp) printf("sec: %d, min: %d, hour: %d, mday: %d, mon: %d, " "year: %d, wday: %d, yday: %d, isdst: %d, gmtoff: %ld, " "zone: %s\n", tp->tm_sec, tp->tm_min, tp->tm_hour, tp->tm_mday, tp->tm_mon, tp->tm_year, tp->tm_wday, tp->tm_yday, tp->tm_isdst, tp->tm_gmtoff, tp->tm_zone); } int main(void) { // time_t t = INT32_MAX; time_t t = 67767976233532799; t_inspect(t-1); t_inspect(t); t_inspect(t+1); t_inspect(t+2); return 0; } The output on a 64 bit machine is (the interesting part is the sec=59) t: 67767976233532798, tp: 0x80085b9a0 errno: 2 sec: 58, min: 59, hour: 23, mday: 31, mon: 11, year: 2147481747, wday: 2, yday: 364, isdst: 0, gmtoff: 0, zone: UTC t: 67767976233532799, tp: 0x80085b9a0 errno: 0 sec: 59, min: 59, hour: 23, mday: 31, mon: 11, year: 2147481747, wday: 2, yday: 364, isdst: 0, gmtoff: 0, zone: UTC t: 67767976233532800, tp: 0x80085b9a0 errno: 0 sec: 59, min: 59, hour: 23, mday: 31, mon: 11, year: 2147481747, wday: 2, yday: 364, isdst: 0, gmtoff: 0, zone: UTC t: 67767976233532801, tp: 0x80085b9a0 errno: 0 sec: 59, min: 59, hour: 23, mday: 31, mon: 11, year: 2147481747, wday: 2, yday: 364, isdst: 0, gmtoff: 0, zone: UTC Right now, I am looking for confirmation from people on the list if this behaviour is also happening on other 64 bit operating systems or that it is a FreeBSD specific quirk. Edwin

3 2

Ponape/Pohnpei
by Clint Adams May 10, 2010

May 10, 2010

It has been brought to my attention that Ponape had been remained to Pohnpei in 1984. Could we switch to Pacific/Pohnpei with a backward link?

2 1

2010j
by Olson, Arthur David (NIH/NCI) [E] May 10, 2010

May 10, 2010

The files... ftp://elsie.nci.nih.gov/pub/tzcode2010j.tar.gz ...and... ftp://elsie.nci.nih.gov/pub/tzdata2010j.tar.gz ...are now available; these reflect the changes circulated on the time zone mailing list for Bahia de Banderas and for version naming. --ado

1 0

Time format error in Olson TZ rules for Asia
by tojo.mathew＠nokia.com April 27, 2010

April 27, 2010

Hello, We have noticed a possible error in Jordan rule. It uses time value 24:00 in recent updates of Olson rule files. Rule Jordan 2002 max - Mar lastThu 24:00 1:00 S As per RFC 3339,( Clause :5.6. Internet Date/Time Format) it recommends time format from 00-23 for hours. (http://www.ietf.org/rfc/rfc3339.txt ) This implies Jordan rule may need to be changed to: Rule Jordan 2002 max - Mar lastFri 0:00 1:00 S Please check this and update in subsequent releases if found appropriate. Regards, Tojo Mathew Senior Engineer,Application S/W Nokia

6 9