Arthur David Olson | 1 May 2010 16:19
Picon

proposed time zone package changes (Bahia de Banderas; version naming)

Here are proposed changes to the time zone package:

	northamerica	New "Bahia_Banderas" time zone (omitting the "de" to stay within 14 characters)
	zone.tab	New "Bahia_Banderas" time zone
	tz-link.htm	Add sentence on time zone version naming.

If no problems are found, these should show up on the ftp site on 2010-05-10.

				--ado

------- northamerica -------
*** /tmp/geta2310	Sat May  1 10:13:44 2010
--- /tmp/getb2310	Sat May  1 10:13:44 2010
***************
*** 1,5 ****
  # <pre>
! #  <at> (#)northamerica	8.30
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.

--- 1,5 ----
  # <pre>
! #  <at> (#)northamerica	8.31
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.

***************
*** 2089,2095 ****
--- 2089,2132 ----
  			-8:00	-	PST	1970
(Continue reading)

Clint Adams | 9 May 2010 14:27
Picon
Favicon

Ponape/Pohnpei

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?

Picon

2010j

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

Picon

RE: Ponape/Pohnpei

While we're in Micronesia...it looks as if Truk was renamed Chuuk in 1989.
If we change one we should presumably change the other.

				--ado

-----Original Message-----
From: Clint Adams [mailto:schizo <at> debian.org] 
Sent: Sunday, May 09, 2010 8:28
To: tz <at> lecserver.nci.nih.gov
Cc: bubulle <at> debian.org; linux <at> wansing-online.de
Subject: Ponape/Pohnpei

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?

Edwin Groothuis | 12 May 2010 05:54
Favicon

gmtime() oddities for large values

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;
(Continue reading)

John Haxby | 12 May 2010 10:05
Picon
Favicon

Re: gmtime() oddities for large values

On 12/05/10 04:54, Edwin Groothuis wrote:
> 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.

It doesn't happen on Fedora 12 (glibc-2.11.1-6) or RHEL4 
(glibc-2.3.4-2.43.el4_8.3 which is quite old).

Let me know if you'd like more information or different tests and I'll 
see what I can do.

jch

walter harms | 13 May 2010 10:37
Picon
Favicon

Re: gmtime() oddities for large values


I have tested on OpenSuSE 11.1. it seems the bug is fixed here.

* Linux 2.6.27.42-0.1-default #1 SMP 2010-01-06 16:07:25 +0100 x86_64 x86_64 x86_64 GNU/Linux
* gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)
* GNU C Library stable release version 2.9 (20081117), by Roland McGrath et al.

t: 67767976233532798, tp: 0x7fc6fc4e3de0 errno: 0
sec: 58, min: 59, hour: 23, mday: 31, mon: 11, year: 2147481747, wday: 2, yday: 364, isdst: 0, gmtoff: 0,
zone: GMT
t: 67767976233532799, tp: 0x7fc6fc4e3de0 errno: 0
sec: 59, min: 59, hour: 23, mday: 31, mon: 11, year: 2147481747, wday: 2, yday: 364, isdst: 0, gmtoff: 0,
zone: GMT
t: 67767976233532800, tp: 0x7fc6fc4e3de0 errno: 0
sec: 0, min: 0, hour: 0, mday: 1, mon: 0, year: 2147481748, wday: 3, yday: 0, isdst: 0, gmtoff: 0, zone: GMT
t: 67767976233532801, tp: 0x7fc6fc4e3de0 errno: 0
sec: 1, min: 0, hour: 0, mday: 1, mon: 0, year: 2147481748, wday: 3, yday: 0, isdst: 0, gmtoff: 0, zone: GMT

re,
 wh

> 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
(Continue reading)

Luther Ma | 15 May 2010 13:40
Picon

Xinjiang Time

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.

(Continue reading)


Gmane