- tz - lists.iana.org

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

Time zone file naming scheme
by Stephen Colebourne April 27, 2010

April 27, 2010

As spec lead of JSR-310, the Java effort to enhance dates and times, I'm encoding TZDB data. In order to represent the different versions of the data, I'm using the tzdb naming scheme or year followed by letter, eg. 2010i. This version number is sorted alphabetically. Obviously, it is possible that there might be more than 26 releases of the data in one year. In order to maintain the alphabetical sort order, I'd like this list to determine a strategy for the unlikely event that this situation occurs. For example: 2010a 2010z 2010za 2010zb If the list does not arrange a strategy (and define it in the theory document), then JSR-310, or future maintainers, will have to make up our own approach for numbering the 27th and onwards releases. Opinions? thanks Stephen

6 6

Subscription request
by tojo.mathew＠nokia.com April 23, 2010

April 23, 2010

I would like to subscribe to this mailing list. Best Regards, Tojo Mathew

1 0

Bahía de Banderas (Mexican state of Nayarit) changed time zone UTC-7 to UTC-6
by Alexander Krivenyshev April 21, 2010

April 21, 2010

According to news, Bahía de Banderas (Mexican state of Nayarit) changed time zone UTC-7 to new time zone UTC-6 on Apriul 4, 2010 (to share the same time zone as nearby city Puerto Vallarta, Jalisco). (Spanish) Bahía de Banderas homologa su horario al del centro del país, a partir de este domingo http://www.nayarit.gob.mx/notes.asp?id=20748 Bahía de Banderas homologa su horario con el del Centro del País http://www.bahiadebanderas.gob.mx/principal/index.php? option=com_content&view=article&id=261:bahia-de-banderas-homologa-su-horario- con-el-del-centro-del-pais&catid=42:comunicacion-social&Itemid=50 (English) Puerto Vallarta and Bahía de Banderas: One Time Zone http://virtualvallarta.com/puertovallarta/puertovallarta/localnews/2009-12-… Puerto-Vallarta-and-Bahia-de-Banderas-One-Time-Zone.shtml or http://www.worldtimezone.com/dst_news/dst_news_mexico08.html "Mexico's Senate approved the amendments to the Mexican Schedule System that will allow Bahía de Banderas and Puerto Vallarta to share the same time zone ..." Alexander Krivenyshev, http://www.worldtimezone.com

1 0

user-friendly time zone list
by Douglass Davis April 20, 2010

April 20, 2010

Hello All, I am attempting to find a user-friendly list of time zones for users to select their current time zone. It would have common names that timezones are referred to, such as Eastern Time (US and Canada), and/or city names. This list should map the text to a time zone name such as "America/New_York." It would also remove multiple listings for what the user thinks of as the same time zone. Does any one know of such a list? If not, I would like to create one. One thing that perhaps would help is if I could group many timezones by if they are implemented exactly the same way in 2010. This would make it easy to remove multiple listings for the "same" time zone. Also, if there are any time zones that are strictly there for historical purposes, I would like to not have them in the list. I will put this list in the public domain if any other application developers want to use it. Please let me know if you have any suggestions as far as where I could find this list, or how I could create it. Thanks. -- Douglass Davis Applications Developer UNC - General Administration

2 2

FW: Creating an alias to America/Sao_Paulo
by Olson, Arthur David (NIH/NCI) [E] April 20, 2010

April 20, 2010

I'm forwarding this message from Leonardo Ferreira, who is not on the time zone mailing list. Those of you who are on the list, please direct replies appropriately. (There are no plans to add an America/Brasilia alias. If it's any consolation, the United States is in a similar boat--the time zone I'm in is named America/New_York rather than America/Washington_DC. --ado From: Leonardo Ferreira Fontenelle [mailto:leonardof@gnome.org] Sent: Sunday, April 18, 2010 10:36 To: tz(a)lecserver.nci.nih.gov Subject: Creating an alias to America/Sao_Paulo I am a GNOME trasnlator, and I received an e-mail from an user about the choice of the São Paulo city as the name for the corresponding time zone. I understand this is the most populous city, but he made a good point: in Brazil we call this time zone "Brasília time". Brasília has been our country capital for 50 years, since the government finished building it for this specific purpose. There's no chance the city will lose this the status for the next decades, because no one has any good reason for that. So, I'd like to know if there's any chance of creating America/Brasilia as an alias to America/Sao_Paulo. Thanks!

2 1