From olsona at lecserver.nci.nih.gov Sat May 1 14:19:16 2010 From: olsona at lecserver.nci.nih.gov (Arthur David Olson) Date: Sat, 1 May 2010 10:19:16 -0400 (EDT) Subject: proposed time zone package changes (Bahia de Banderas; version naming) Message-ID: <201005011419.o41EJGjt002390@lecserver.nci.nih.gov> 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 **** #
! # @(#)northamerica	8.30
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.
  
--- 1,5 ----
  # ! # @(#)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
  			-7:00	Mexico	M%sT	1999
  			-7:00	-	MST
+ 
+ # From Alexander Krivenyshev (2010-04-21):
+ # According to news, Bahía de Banderas (Mexican state of Nayarit)
+ # changed time zone UTC-7 to new time zone UTC-6 on April 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-03-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 ..."
  # Baja California Sur, Nayarit, Sinaloa
+ 
+ # From Arthur David Olson (2010-05-01):
+ # Use "Bahia_Banderas" to keep the name to fourteen characters.
+ 
  Zone America/Mazatlan	-7:05:40 -	LMT	1921 Dec 31 23:54:20
  			-7:00	-	MST	1927 Jun 10 23:00
  			-6:00	-	CST	1930 Nov 15
***************
*** 2100,2105 ****
--- 2137,2155 ----
  			-7:00	-	MST	1949 Jan 14
  			-8:00	-	PST	1970
  			-7:00	Mexico	M%sT
+ 
+ Zone America/Bahia_Banderas	-7:01:00 -	LMT	1921 Dec 31 23:59:00
+ 			-7:00	-	MST	1927 Jun 10 23:00
+ 			-6:00	-	CST	1930 Nov 15
+ 			-7:00	-	MST	1931 May  1 23:00
+ 			-6:00	-	CST	1931 Oct
+ 			-7:00	-	MST	1932 Apr  1
+ 			-6:00	-	CST	1942 Apr 24
+ 			-7:00	-	MST	1949 Jan 14
+ 			-8:00	-	PST	1970
+ 			-7:00	Mexico	M%sT	2010 Apr 4
+ 			-6:00	Mexico	C%sT
+ 
  # Baja California (near US border)
  Zone America/Tijuana	-7:48:04 -	LMT	1922 Jan  1  0:11:56
  			-7:00	-	MST	1924

------- tz-link.htm -------
*** /tmp/geta2330	Sat May  1 10:14:05 2010
--- /tmp/getb2330	Sat May  1 10:14:05 2010
***************
*** 18,24 ****
  
  Sources for Time Zone and Daylight Saving Time Data
  
! @(#)tz-link.htm	8.26
  
  
  This file is in the public domain, so clarified as of
--- 18,24 ----
  
  
Sources for Time Zone and Daylight Saving Time Data
  
! @(#)tz-link.htm	8.27
  
  
  This file is in the public domain, so clarified as of
***************
*** 89,94 ****
--- 89,96 ----
  where C is the code's version;
  similarly, the data are in tzdataD.tar.gz,
  where D is the data's version.
+ Each version is a four-digit year followed by lower-case letters
+ (a through z, then za through zz, then zza through zzz, and so on).
  The following shell commands download
  these files to a GNU/Linux or similar host;

------- zone.tab -------
*** /tmp/geta2358	Sat May  1 10:14:46 2010
--- /tmp/getb2358	Sat May  1 10:14:46 2010
***************
*** 1,5 ****
  # 
! # @(#)zone.tab	8.35
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.
  #
--- 1,5 ----
  # ! # @(#)zone.tab	8.36
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.
  #
***************
*** 288,293 ****
--- 288,294 ----
  MX	+2904-11058	America/Hermosillo	Mountain Standard Time - Sonora
  MX	+3232-11701	America/Tijuana	US Pacific Time - Baja California near US border
  MX	+3018-11452	America/Santa_Isabel	Mexican Pacific Time - Baja California away from US border
+ MX	+2048-10515	America/Bahia_Banderas	Mexican Central Time - Bahia de Banderas
  MY	+0310+10142	Asia/Kuala_Lumpur	peninsular Malaysia
  MY	+0133+11020	Asia/Kuching	Sabah & Sarawak
  MZ	-2558+03235	Africa/Maputo


From schizo at debian.org  Sun May  9 12:27:30 2010
From: schizo at debian.org (Clint Adams)
Date: Sun, 9 May 2010 12:27:30 +0000
Subject: Ponape/Pohnpei
Message-ID: <20100509122730.GA27034@scru.org>

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?


From olsona at dc37a.nci.nih.gov  Mon May 10 13:11:45 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Mon, 10 May 2010 09:11:45 -0400
Subject: 2010j
Message-ID: <996D816825CFEA469870126E9050D3F0E1F8DEB3@NIHMLBX11.nih.gov>

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


From olsona at dc37a.nci.nih.gov  Mon May 10 21:01:49 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Mon, 10 May 2010 17:01:49 -0400
Subject: Ponape/Pohnpei
In-Reply-To: <20100509122730.GA27034@scru.org>
References: <20100509122730.GA27034@scru.org>
Message-ID: <996D816825CFEA469870126E9050D3F0E1F8DEB9@NIHMLBX11.nih.gov>

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?


From edwin at mavetju.org  Wed May 12 03:54:50 2010
From: edwin at mavetju.org (Edwin Groothuis)
Date: Wed, 12 May 2010 03:54:50 +0000 (UTC)
Subject: gmtime() oddities for large values
Message-ID: 

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 
    #include 
    #include 
    #include 

    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




From john.haxby at oracle.com  Wed May 12 08:05:34 2010
From: john.haxby at oracle.com (John Haxby)
Date: Wed, 12 May 2010 09:05:34 +0100
Subject: gmtime() oddities for large values
In-Reply-To: 
References: 
Message-ID: <4BEA614E.3000605@oracle.com>

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


From wharms at bfs.de  Thu May 13 08:37:59 2010
From: wharms at bfs.de (walter harms)
Date: Thu, 13 May 2010 10:37:59 +0200
Subject: gmtime() oddities for large values
In-Reply-To: 
References: 
Message-ID: <4BEBBA67.9010509@bfs.de>


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
> 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
> 
> 
> 
> 


From ma.lude.xj at gmail.com  Sat May 15 11:40:59 2010
From: ma.lude.xj at gmail.com (Luther Ma)
Date: Sat, 15 May 2010 17:40:59 +0600
Subject: Xinjiang Time
Message-ID: <58A3F92F-7A71-4F9C-9FD0-2B13590885B7@gmail.com>

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):


From adraa.maameri at capgemini.com  Tue May 18 16:16:32 2010
From: adraa.maameri at capgemini.com (Maameri, Adraa)
Date: Tue, 18 May 2010 18:16:32 +0200
Subject: =?iso-8859-1?Q?Information_Requet=E9?=
Message-ID: <3DA72F2AEA1EFE43A7033DE6D38FBB6D5A007D0B@CORPMAIL07.corp.capgemini.com>

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,



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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20100518/796baecb/attachment.html 

From gary.lasker at canonical.com  Tue May 25 02:24:44 2010
From: gary.lasker at canonical.com (Gary Lasker)
Date: Mon, 24 May 2010 22:24:44 -0400
Subject: Russian time zone issue reported
Message-ID: <4BFB34EC.4070906@canonical.com>


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


From ilya.dogolazky at nokia.com  Tue May 25 04:54:49 2010
From: ilya.dogolazky at nokia.com (Ilya Dogolazky)
Date: Tue, 25 May 2010 07:54:49 +0300
Subject: Russian time zone issue reported
In-Reply-To: <4BFB34EC.4070906@canonical.com>
References: <4BFB34EC.4070906@canonical.com>
Message-ID: <4BFB5819.4030801@nokia.com>

Hi !

It says: There is an official decision to use Moscow time in Samara 
region http://www.svobodanews.ru/content/article/1991161.html (in Russian)

But there is a petition against this decision, and they hope to undo it 
during the next summer->winter switch: "?? ?????? ????? ????? "????????? 
?????", ???????? ?????????? ???? ??????? ????????, ???? ?????????? 
???????? ??? ???????? ?? ?????? ??????????? ??????? ????? ?????????????, 
?? ?????? ? ?????? ???? ???? ??????? ????????? ?????". But it's purely 
theoretical: usually Russian rulers don't care about the people's petitions.

According to this 
http://www.svobodanews.ru/archive/ru_news_zone/20100328/17/17.html?id=1995554 
the Udmurtia region is now using Moscow time as well (Europe/Samara was 
in use in exactly two regions: Samara and Udmurtia). This link says "the 
amount of time zones in Russia is reduced from 11 to 9". I think you can 
assume, that Samara and Kamchatka zones are not existing any more.

BR

Ilya Dogolazky
Maemo Devices
Nokia

ext Gary Lasker wrote:
> 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
>
>   


From olsona at dc37a.nci.nih.gov  Tue May 25 15:09:08 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Tue, 25 May 2010 11:09:08 -0400
Subject: FW: Timezone option
Message-ID: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>

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 at rediffmail.com] 
Sent: Tuesday, May 25, 2010 3:36
To: tz at 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,






From olsona at dc37a.nci.nih.gov  Tue May 25 16:10:46 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Tue, 25 May 2010 12:10:46 -0400
Subject: Russian time zone issue reported
In-Reply-To: <4BFB34EC.4070906@canonical.com>
References: <4BFB34EC.4070906@canonical.com>
Message-ID: <996D816825CFEA469870126E9050D3F0E920604C@NIHMLBX11.nih.gov>

> "Europe/Samara is now exactly equal Europe/Moscow, Asia/Kamchatka is Asia/Magadan."

Which is not to say that Europe/Samara and Asia/Kamchatka will disappear as time zones--both for the benefit of folks who have their time zone environment variables set to those values and to ensure that lookups of past times in Samara and Kamchatka yield correct results.

				--ado

-----Original Message-----
From: Gary Lasker [mailto:gary.lasker at canonical.com] 
Sent: Monday, May 24, 2010 10:25
To: tz at lecserver.nci.nih.gov; Gary Lasker; martin.pitt at canonical.com
Subject: Russian time zone issue reported


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




From ghane0 at gmail.com  Tue May 25 16:19:22 2010
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 26 May 2010 00:19:22 +0800
Subject: FW: Timezone option
In-Reply-To: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>
References: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>
Message-ID: 

Hi,

In 1994, I tested with TZ offsets of 720 hours.  This was on an SVR4 Unix
from Unisys, for an application where they wanted to test reminder
generation within the app.

I would set and export TZ, then start a shell, and run the application
inside it.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane


On Tue, May 25, 2010 at 23:09, Olson, Arthur David (NIH/NCI) [E] <
olsona at dc37a.nci.nih.gov> wrote:

> 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 at rediffmail.com]
> Sent: Tuesday, May 25, 2010 3:36
> To: tz at 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,
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20100526/90abe5eb/attachment.html 

From Paul_Koning at Dell.com  Tue May 25 16:25:45 2010
From: Paul_Koning at Dell.com (Paul Koning)
Date: Tue, 25 May 2010 12:25:45 -0400
Subject: FW: Timezone option
In-Reply-To: 
References: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov> 
Message-ID: 

Note that this only works if you want to test offsets to local time.  If
the test requires offsetting UTC - which is normally what operating
systems use internally - then the timezone machinery is no help and you
have to use the normal system services to set the system clock anyway.
That may be easier in any case.

 

                paul

 

From: Sanjeev Gupta [mailto:ghane0 at gmail.com] 
Sent: Tuesday, May 25, 2010 12:19 PM
To: tz at lecserver.nci.nih.gov
Cc: honeybajaj1 at rediffmail.com
Subject: Re: FW: Timezone option

 

Hi,

In 1994, I tested with TZ offsets of 720 hours.  This was on an SVR4
Unix from Unisys, for an application where they wanted to test reminder
generation within the app.

I would set and export TZ, then start a shell, and run the application
inside it.
 
-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane



On Tue, May 25, 2010 at 23:09, Olson, Arthur David (NIH/NCI) [E]
 wrote:

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 at rediffmail.com]
Sent: Tuesday, May 25, 2010 3:36
To: tz at 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,





 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20100525/ab3b383e/attachment.html 

From jaakko.hyvatti at foreca.com  Wed May 26 02:29:15 2010
From: jaakko.hyvatti at foreca.com (=?ISO-8859-15?Q?Jaakko_Hyv=E4tti?=)
Date: Wed, 26 May 2010 05:29:15 +0300 (EEST)
Subject: FW: Timezone option
In-Reply-To: 
References: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>  
Message-ID: 


Hi,

You could create a dynamic library that replaces necessary system calls, 
like calls to time() or gettimeofday(), and link it or load it to your 
application with LD_LIBRARY_PRELOAD environment variable.  libc versions 
of these syscalls are weak symbols and user libraries override them.

Jaakko


> From: honey bajaj [mailto:honeybajaj1 at rediffmail.com]
> Sent: Tuesday, May 25, 2010 3:36
> To: tz at 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,


-- 
Foreca Ltd                                           Jaakko.Hyvatti at foreca.com
Tammasaarenkatu 5, FI-00180 Helsinki, Finland        http://www.foreca.com


From olsona at lecserver.nci.nih.gov  Sat May  1 14:19:16 2010
From: olsona at lecserver.nci.nih.gov (Arthur David Olson)
Date: Sat, 1 May 2010 10:19:16 -0400 (EDT)
Subject: proposed time zone package changes (Bahia de Banderas; version naming)
Message-ID: <201005011419.o41EJGjt002390@lecserver.nci.nih.gov>

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 ****
  # ! # @(#)northamerica	8.30
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.
  
--- 1,5 ----
  # ! # @(#)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
  			-7:00	Mexico	M%sT	1999
  			-7:00	-	MST
+ 
+ # From Alexander Krivenyshev (2010-04-21):
+ # According to news, Bahía de Banderas (Mexican state of Nayarit)
+ # changed time zone UTC-7 to new time zone UTC-6 on April 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-03-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 ..."
  # Baja California Sur, Nayarit, Sinaloa
+ 
+ # From Arthur David Olson (2010-05-01):
+ # Use "Bahia_Banderas" to keep the name to fourteen characters.
+ 
  Zone America/Mazatlan	-7:05:40 -	LMT	1921 Dec 31 23:54:20
  			-7:00	-	MST	1927 Jun 10 23:00
  			-6:00	-	CST	1930 Nov 15
***************
*** 2100,2105 ****
--- 2137,2155 ----
  			-7:00	-	MST	1949 Jan 14
  			-8:00	-	PST	1970
  			-7:00	Mexico	M%sT
+ 
+ Zone America/Bahia_Banderas	-7:01:00 -	LMT	1921 Dec 31 23:59:00
+ 			-7:00	-	MST	1927 Jun 10 23:00
+ 			-6:00	-	CST	1930 Nov 15
+ 			-7:00	-	MST	1931 May  1 23:00
+ 			-6:00	-	CST	1931 Oct
+ 			-7:00	-	MST	1932 Apr  1
+ 			-6:00	-	CST	1942 Apr 24
+ 			-7:00	-	MST	1949 Jan 14
+ 			-8:00	-	PST	1970
+ 			-7:00	Mexico	M%sT	2010 Apr 4
+ 			-6:00	Mexico	C%sT
+ 
  # Baja California (near US border)
  Zone America/Tijuana	-7:48:04 -	LMT	1922 Jan  1  0:11:56
  			-7:00	-	MST	1924

------- tz-link.htm -------
*** /tmp/geta2330	Sat May  1 10:14:05 2010
--- /tmp/getb2330	Sat May  1 10:14:05 2010
***************
*** 18,24 ****
  
  Sources for Time Zone and Daylight Saving Time Data
  
! @(#)tz-link.htm	8.26
  
  
  This file is in the public domain, so clarified as of
--- 18,24 ----
  
  
Sources for Time Zone and Daylight Saving Time Data
  
! @(#)tz-link.htm	8.27
  
  
  This file is in the public domain, so clarified as of
***************
*** 89,94 ****
--- 89,96 ----
  where C is the code's version;
  similarly, the data are in tzdataD.tar.gz,
  where D is the data's version.
+ Each version is a four-digit year followed by lower-case letters
+ (a through z, then za through zz, then zza through zzz, and so on).
  The following shell commands download
  these files to a GNU/Linux or similar host;

------- zone.tab -------
*** /tmp/geta2358	Sat May  1 10:14:46 2010
--- /tmp/getb2358	Sat May  1 10:14:46 2010
***************
*** 1,5 ****
  # 
! # @(#)zone.tab	8.35
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.
  #
--- 1,5 ----
  # ! # @(#)zone.tab	8.36
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.
  #
***************
*** 288,293 ****
--- 288,294 ----
  MX	+2904-11058	America/Hermosillo	Mountain Standard Time - Sonora
  MX	+3232-11701	America/Tijuana	US Pacific Time - Baja California near US border
  MX	+3018-11452	America/Santa_Isabel	Mexican Pacific Time - Baja California away from US border
+ MX	+2048-10515	America/Bahia_Banderas	Mexican Central Time - Bahia de Banderas
  MY	+0310+10142	Asia/Kuala_Lumpur	peninsular Malaysia
  MY	+0133+11020	Asia/Kuching	Sabah & Sarawak
  MZ	-2558+03235	Africa/Maputo


From schizo at debian.org  Sun May  9 12:27:30 2010
From: schizo at debian.org (Clint Adams)
Date: Sun, 9 May 2010 12:27:30 +0000
Subject: Ponape/Pohnpei
Message-ID: <20100509122730.GA27034@scru.org>

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?


From olsona at dc37a.nci.nih.gov  Mon May 10 13:11:45 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Mon, 10 May 2010 09:11:45 -0400
Subject: 2010j
Message-ID: <996D816825CFEA469870126E9050D3F0E1F8DEB3@NIHMLBX11.nih.gov>

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


From olsona at dc37a.nci.nih.gov  Mon May 10 21:01:49 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Mon, 10 May 2010 17:01:49 -0400
Subject: Ponape/Pohnpei
In-Reply-To: <20100509122730.GA27034@scru.org>
References: <20100509122730.GA27034@scru.org>
Message-ID: <996D816825CFEA469870126E9050D3F0E1F8DEB9@NIHMLBX11.nih.gov>

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?


From edwin at mavetju.org  Wed May 12 03:54:50 2010
From: edwin at mavetju.org (Edwin Groothuis)
Date: Wed, 12 May 2010 03:54:50 +0000 (UTC)
Subject: gmtime() oddities for large values
Message-ID: 

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 
    #include 
    #include 
    #include 

    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




From john.haxby at oracle.com  Wed May 12 08:05:34 2010
From: john.haxby at oracle.com (John Haxby)
Date: Wed, 12 May 2010 09:05:34 +0100
Subject: gmtime() oddities for large values
In-Reply-To: 
References: 
Message-ID: <4BEA614E.3000605@oracle.com>

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


From wharms at bfs.de  Thu May 13 08:37:59 2010
From: wharms at bfs.de (walter harms)
Date: Thu, 13 May 2010 10:37:59 +0200
Subject: gmtime() oddities for large values
In-Reply-To: 
References: 
Message-ID: <4BEBBA67.9010509@bfs.de>


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
> 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
> 
> 
> 
> 


From ma.lude.xj at gmail.com  Sat May 15 11:40:59 2010
From: ma.lude.xj at gmail.com (Luther Ma)
Date: Sat, 15 May 2010 17:40:59 +0600
Subject: Xinjiang Time
Message-ID: <58A3F92F-7A71-4F9C-9FD0-2B13590885B7@gmail.com>

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):


From adraa.maameri at capgemini.com  Tue May 18 16:16:32 2010
From: adraa.maameri at capgemini.com (Maameri, Adraa)
Date: Tue, 18 May 2010 18:16:32 +0200
Subject: =?iso-8859-1?Q?Information_Requet=E9?=
Message-ID: <3DA72F2AEA1EFE43A7033DE6D38FBB6D5A007D0B@CORPMAIL07.corp.capgemini.com>

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,



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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20100518/796baecb/attachment-0001.html 

From gary.lasker at canonical.com  Tue May 25 02:24:44 2010
From: gary.lasker at canonical.com (Gary Lasker)
Date: Mon, 24 May 2010 22:24:44 -0400
Subject: Russian time zone issue reported
Message-ID: <4BFB34EC.4070906@canonical.com>


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


From ilya.dogolazky at nokia.com  Tue May 25 04:54:49 2010
From: ilya.dogolazky at nokia.com (Ilya Dogolazky)
Date: Tue, 25 May 2010 07:54:49 +0300
Subject: Russian time zone issue reported
In-Reply-To: <4BFB34EC.4070906@canonical.com>
References: <4BFB34EC.4070906@canonical.com>
Message-ID: <4BFB5819.4030801@nokia.com>

Hi !

It says: There is an official decision to use Moscow time in Samara 
region http://www.svobodanews.ru/content/article/1991161.html (in Russian)

But there is a petition against this decision, and they hope to undo it 
during the next summer->winter switch: "?? ?????? ????? ????? "????????? 
?????", ???????? ?????????? ???? ??????? ????????, ???? ?????????? 
???????? ??? ???????? ?? ?????? ??????????? ??????? ????? ?????????????, 
?? ?????? ? ?????? ???? ???? ??????? ????????? ?????". But it's purely 
theoretical: usually Russian rulers don't care about the people's petitions.

According to this 
http://www.svobodanews.ru/archive/ru_news_zone/20100328/17/17.html?id=1995554 
the Udmurtia region is now using Moscow time as well (Europe/Samara was 
in use in exactly two regions: Samara and Udmurtia). This link says "the 
amount of time zones in Russia is reduced from 11 to 9". I think you can 
assume, that Samara and Kamchatka zones are not existing any more.

BR

Ilya Dogolazky
Maemo Devices
Nokia

ext Gary Lasker wrote:
> 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
>
>   


From olsona at dc37a.nci.nih.gov  Tue May 25 15:09:08 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Tue, 25 May 2010 11:09:08 -0400
Subject: FW: Timezone option
Message-ID: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>

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 at rediffmail.com] 
Sent: Tuesday, May 25, 2010 3:36
To: tz at 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,






From olsona at dc37a.nci.nih.gov  Tue May 25 16:10:46 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Tue, 25 May 2010 12:10:46 -0400
Subject: Russian time zone issue reported
In-Reply-To: <4BFB34EC.4070906@canonical.com>
References: <4BFB34EC.4070906@canonical.com>
Message-ID: <996D816825CFEA469870126E9050D3F0E920604C@NIHMLBX11.nih.gov>

> "Europe/Samara is now exactly equal Europe/Moscow, Asia/Kamchatka is Asia/Magadan."

Which is not to say that Europe/Samara and Asia/Kamchatka will disappear as time zones--both for the benefit of folks who have their time zone environment variables set to those values and to ensure that lookups of past times in Samara and Kamchatka yield correct results.

				--ado

-----Original Message-----
From: Gary Lasker [mailto:gary.lasker at canonical.com] 
Sent: Monday, May 24, 2010 10:25
To: tz at lecserver.nci.nih.gov; Gary Lasker; martin.pitt at canonical.com
Subject: Russian time zone issue reported


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




From ghane0 at gmail.com  Tue May 25 16:19:22 2010
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 26 May 2010 00:19:22 +0800
Subject: FW: Timezone option
In-Reply-To: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>
References: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>
Message-ID: 

Hi,

In 1994, I tested with TZ offsets of 720 hours.  This was on an SVR4 Unix
from Unisys, for an application where they wanted to test reminder
generation within the app.

I would set and export TZ, then start a shell, and run the application
inside it.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane


On Tue, May 25, 2010 at 23:09, Olson, Arthur David (NIH/NCI) [E] <
olsona at dc37a.nci.nih.gov> wrote:

> 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 at rediffmail.com]
> Sent: Tuesday, May 25, 2010 3:36
> To: tz at 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,
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20100526/90abe5eb/attachment-0001.html 

From Paul_Koning at Dell.com  Tue May 25 16:25:45 2010
From: Paul_Koning at Dell.com (Paul Koning)
Date: Tue, 25 May 2010 12:25:45 -0400
Subject: FW: Timezone option
In-Reply-To: 
References: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov> 
Message-ID: 

Note that this only works if you want to test offsets to local time.  If
the test requires offsetting UTC - which is normally what operating
systems use internally - then the timezone machinery is no help and you
have to use the normal system services to set the system clock anyway.
That may be easier in any case.

 

                paul

 

From: Sanjeev Gupta [mailto:ghane0 at gmail.com] 
Sent: Tuesday, May 25, 2010 12:19 PM
To: tz at lecserver.nci.nih.gov
Cc: honeybajaj1 at rediffmail.com
Subject: Re: FW: Timezone option

 

Hi,

In 1994, I tested with TZ offsets of 720 hours.  This was on an SVR4
Unix from Unisys, for an application where they wanted to test reminder
generation within the app.

I would set and export TZ, then start a shell, and run the application
inside it.
 
-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane



On Tue, May 25, 2010 at 23:09, Olson, Arthur David (NIH/NCI) [E]
 wrote:

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 at rediffmail.com]
Sent: Tuesday, May 25, 2010 3:36
To: tz at 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,





 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20100525/ab3b383e/attachment-0001.html 

From jaakko.hyvatti at foreca.com  Wed May 26 02:29:15 2010
From: jaakko.hyvatti at foreca.com (=?ISO-8859-15?Q?Jaakko_Hyv=E4tti?=)
Date: Wed, 26 May 2010 05:29:15 +0300 (EEST)
Subject: FW: Timezone option
In-Reply-To: 
References: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>  
Message-ID: 


Hi,

You could create a dynamic library that replaces necessary system calls, 
like calls to time() or gettimeofday(), and link it or load it to your 
application with LD_LIBRARY_PRELOAD environment variable.  libc versions 
of these syscalls are weak symbols and user libraries override them.

Jaakko


> From: honey bajaj [mailto:honeybajaj1 at rediffmail.com]
> Sent: Tuesday, May 25, 2010 3:36
> To: tz at 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,


-- 
Foreca Ltd                                           Jaakko.Hyvatti at foreca.com
Tammasaarenkatu 5, FI-00180 Helsinki, Finland        http://www.foreca.com


From olsona at lecserver.nci.nih.gov  Sat May  1 14:19:16 2010
From: olsona at lecserver.nci.nih.gov (Arthur David Olson)
Date: Sat, 1 May 2010 10:19:16 -0400 (EDT)
Subject: proposed time zone package changes (Bahia de Banderas; version naming)
Message-ID: <201005011419.o41EJGjt002390@lecserver.nci.nih.gov>

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 ****
  # ! # @(#)northamerica	8.30
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.
  
--- 1,5 ----
  # ! # @(#)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
  			-7:00	Mexico	M%sT	1999
  			-7:00	-	MST
+ 
+ # From Alexander Krivenyshev (2010-04-21):
+ # According to news, Bahía de Banderas (Mexican state of Nayarit)
+ # changed time zone UTC-7 to new time zone UTC-6 on April 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-03-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 ..."
  # Baja California Sur, Nayarit, Sinaloa
+ 
+ # From Arthur David Olson (2010-05-01):
+ # Use "Bahia_Banderas" to keep the name to fourteen characters.
+ 
  Zone America/Mazatlan	-7:05:40 -	LMT	1921 Dec 31 23:54:20
  			-7:00	-	MST	1927 Jun 10 23:00
  			-6:00	-	CST	1930 Nov 15
***************
*** 2100,2105 ****
--- 2137,2155 ----
  			-7:00	-	MST	1949 Jan 14
  			-8:00	-	PST	1970
  			-7:00	Mexico	M%sT
+ 
+ Zone America/Bahia_Banderas	-7:01:00 -	LMT	1921 Dec 31 23:59:00
+ 			-7:00	-	MST	1927 Jun 10 23:00
+ 			-6:00	-	CST	1930 Nov 15
+ 			-7:00	-	MST	1931 May  1 23:00
+ 			-6:00	-	CST	1931 Oct
+ 			-7:00	-	MST	1932 Apr  1
+ 			-6:00	-	CST	1942 Apr 24
+ 			-7:00	-	MST	1949 Jan 14
+ 			-8:00	-	PST	1970
+ 			-7:00	Mexico	M%sT	2010 Apr 4
+ 			-6:00	Mexico	C%sT
+ 
  # Baja California (near US border)
  Zone America/Tijuana	-7:48:04 -	LMT	1922 Jan  1  0:11:56
  			-7:00	-	MST	1924

------- tz-link.htm -------
*** /tmp/geta2330	Sat May  1 10:14:05 2010
--- /tmp/getb2330	Sat May  1 10:14:05 2010
***************
*** 18,24 ****
  
  Sources for Time Zone and Daylight Saving Time Data
  
! @(#)tz-link.htm	8.26
  
  
  This file is in the public domain, so clarified as of
--- 18,24 ----
  
  
Sources for Time Zone and Daylight Saving Time Data
  
! @(#)tz-link.htm	8.27
  
  
  This file is in the public domain, so clarified as of
***************
*** 89,94 ****
--- 89,96 ----
  where C is the code's version;
  similarly, the data are in tzdataD.tar.gz,
  where D is the data's version.
+ Each version is a four-digit year followed by lower-case letters
+ (a through z, then za through zz, then zza through zzz, and so on).
  The following shell commands download
  these files to a GNU/Linux or similar host;

------- zone.tab -------
*** /tmp/geta2358	Sat May  1 10:14:46 2010
--- /tmp/getb2358	Sat May  1 10:14:46 2010
***************
*** 1,5 ****
  # 
! # @(#)zone.tab	8.35
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.
  #
--- 1,5 ----
  # ! # @(#)zone.tab	8.36
  # This file is in the public domain, so clarified as of
  # 2009-05-17 by Arthur David Olson.
  #
***************
*** 288,293 ****
--- 288,294 ----
  MX	+2904-11058	America/Hermosillo	Mountain Standard Time - Sonora
  MX	+3232-11701	America/Tijuana	US Pacific Time - Baja California near US border
  MX	+3018-11452	America/Santa_Isabel	Mexican Pacific Time - Baja California away from US border
+ MX	+2048-10515	America/Bahia_Banderas	Mexican Central Time - Bahia de Banderas
  MY	+0310+10142	Asia/Kuala_Lumpur	peninsular Malaysia
  MY	+0133+11020	Asia/Kuching	Sabah & Sarawak
  MZ	-2558+03235	Africa/Maputo


From schizo at debian.org  Sun May  9 12:27:30 2010
From: schizo at debian.org (Clint Adams)
Date: Sun, 9 May 2010 12:27:30 +0000
Subject: Ponape/Pohnpei
Message-ID: <20100509122730.GA27034@scru.org>

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?


From olsona at dc37a.nci.nih.gov  Mon May 10 13:11:45 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Mon, 10 May 2010 09:11:45 -0400
Subject: 2010j
Message-ID: <996D816825CFEA469870126E9050D3F0E1F8DEB3@NIHMLBX11.nih.gov>

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


From olsona at dc37a.nci.nih.gov  Mon May 10 21:01:49 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Mon, 10 May 2010 17:01:49 -0400
Subject: Ponape/Pohnpei
In-Reply-To: <20100509122730.GA27034@scru.org>
References: <20100509122730.GA27034@scru.org>
Message-ID: <996D816825CFEA469870126E9050D3F0E1F8DEB9@NIHMLBX11.nih.gov>

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?


From edwin at mavetju.org  Wed May 12 03:54:50 2010
From: edwin at mavetju.org (Edwin Groothuis)
Date: Wed, 12 May 2010 03:54:50 +0000 (UTC)
Subject: gmtime() oddities for large values
Message-ID: 

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 
    #include 
    #include 
    #include 

    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




From john.haxby at oracle.com  Wed May 12 08:05:34 2010
From: john.haxby at oracle.com (John Haxby)
Date: Wed, 12 May 2010 09:05:34 +0100
Subject: gmtime() oddities for large values
In-Reply-To: 
References: 
Message-ID: <4BEA614E.3000605@oracle.com>

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


From wharms at bfs.de  Thu May 13 08:37:59 2010
From: wharms at bfs.de (walter harms)
Date: Thu, 13 May 2010 10:37:59 +0200
Subject: gmtime() oddities for large values
In-Reply-To: 
References: 
Message-ID: <4BEBBA67.9010509@bfs.de>


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
> 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
> 
> 
> 
> 


From ma.lude.xj at gmail.com  Sat May 15 11:40:59 2010
From: ma.lude.xj at gmail.com (Luther Ma)
Date: Sat, 15 May 2010 17:40:59 +0600
Subject: Xinjiang Time
Message-ID: <58A3F92F-7A71-4F9C-9FD0-2B13590885B7@gmail.com>

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):


From adraa.maameri at capgemini.com  Tue May 18 16:16:32 2010
From: adraa.maameri at capgemini.com (Maameri, Adraa)
Date: Tue, 18 May 2010 18:16:32 +0200
Subject: =?iso-8859-1?Q?Information_Requet=E9?=
Message-ID: <3DA72F2AEA1EFE43A7033DE6D38FBB6D5A007D0B@CORPMAIL07.corp.capgemini.com>

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,



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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From gary.lasker at canonical.com  Tue May 25 02:24:44 2010
From: gary.lasker at canonical.com (Gary Lasker)
Date: Mon, 24 May 2010 22:24:44 -0400
Subject: Russian time zone issue reported
Message-ID: <4BFB34EC.4070906@canonical.com>


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


From ilya.dogolazky at nokia.com  Tue May 25 04:54:49 2010
From: ilya.dogolazky at nokia.com (Ilya Dogolazky)
Date: Tue, 25 May 2010 07:54:49 +0300
Subject: Russian time zone issue reported
In-Reply-To: <4BFB34EC.4070906@canonical.com>
References: <4BFB34EC.4070906@canonical.com>
Message-ID: <4BFB5819.4030801@nokia.com>

Hi !

It says: There is an official decision to use Moscow time in Samara 
region http://www.svobodanews.ru/content/article/1991161.html (in Russian)

But there is a petition against this decision, and they hope to undo it 
during the next summer->winter switch: "?? ?????? ????? ????? "????????? 
?????", ???????? ?????????? ???? ??????? ????????, ???? ?????????? 
???????? ??? ???????? ?? ?????? ??????????? ??????? ????? ?????????????, 
?? ?????? ? ?????? ???? ???? ??????? ????????? ?????". But it's purely 
theoretical: usually Russian rulers don't care about the people's petitions.

According to this 
http://www.svobodanews.ru/archive/ru_news_zone/20100328/17/17.html?id=1995554 
the Udmurtia region is now using Moscow time as well (Europe/Samara was 
in use in exactly two regions: Samara and Udmurtia). This link says "the 
amount of time zones in Russia is reduced from 11 to 9". I think you can 
assume, that Samara and Kamchatka zones are not existing any more.

BR

Ilya Dogolazky
Maemo Devices
Nokia

ext Gary Lasker wrote:
> 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
>
>   


From olsona at dc37a.nci.nih.gov  Tue May 25 15:09:08 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Tue, 25 May 2010 11:09:08 -0400
Subject: FW: Timezone option
Message-ID: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>

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 at rediffmail.com] 
Sent: Tuesday, May 25, 2010 3:36
To: tz at 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,






From olsona at dc37a.nci.nih.gov  Tue May 25 16:10:46 2010
From: olsona at dc37a.nci.nih.gov (Olson, Arthur David (NIH/NCI) [E])
Date: Tue, 25 May 2010 12:10:46 -0400
Subject: Russian time zone issue reported
In-Reply-To: <4BFB34EC.4070906@canonical.com>
References: <4BFB34EC.4070906@canonical.com>
Message-ID: <996D816825CFEA469870126E9050D3F0E920604C@NIHMLBX11.nih.gov>

> "Europe/Samara is now exactly equal Europe/Moscow, Asia/Kamchatka is Asia/Magadan."

Which is not to say that Europe/Samara and Asia/Kamchatka will disappear as time zones--both for the benefit of folks who have their time zone environment variables set to those values and to ensure that lookups of past times in Samara and Kamchatka yield correct results.

				--ado

-----Original Message-----
From: Gary Lasker [mailto:gary.lasker at canonical.com] 
Sent: Monday, May 24, 2010 10:25
To: tz at lecserver.nci.nih.gov; Gary Lasker; martin.pitt at canonical.com
Subject: Russian time zone issue reported


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




From ghane0 at gmail.com  Tue May 25 16:19:22 2010
From: ghane0 at gmail.com (Sanjeev Gupta)
Date: Wed, 26 May 2010 00:19:22 +0800
Subject: FW: Timezone option
In-Reply-To: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>
References: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>
Message-ID: 

Hi,

In 1994, I tested with TZ offsets of 720 hours.  This was on an SVR4 Unix
from Unisys, for an application where they wanted to test reminder
generation within the app.

I would set and export TZ, then start a shell, and run the application
inside it.

-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane


On Tue, May 25, 2010 at 23:09, Olson, Arthur David (NIH/NCI) [E] <
olsona at dc37a.nci.nih.gov> wrote:

> 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 at rediffmail.com]
> Sent: Tuesday, May 25, 2010 3:36
> To: tz at 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,
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From Paul_Koning at Dell.com  Tue May 25 16:25:45 2010
From: Paul_Koning at Dell.com (Paul Koning)
Date: Tue, 25 May 2010 12:25:45 -0400
Subject: FW: Timezone option
In-Reply-To: 
References: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov> 
Message-ID: 

Note that this only works if you want to test offsets to local time.  If
the test requires offsetting UTC - which is normally what operating
systems use internally - then the timezone machinery is no help and you
have to use the normal system services to set the system clock anyway.
That may be easier in any case.

 

                paul

 

From: Sanjeev Gupta [mailto:ghane0 at gmail.com] 
Sent: Tuesday, May 25, 2010 12:19 PM
To: tz at lecserver.nci.nih.gov
Cc: honeybajaj1 at rediffmail.com
Subject: Re: FW: Timezone option

 

Hi,

In 1994, I tested with TZ offsets of 720 hours.  This was on an SVR4
Unix from Unisys, for an application where they wanted to test reminder
generation within the app.

I would set and export TZ, then start a shell, and run the application
inside it.
 
-- 
Sanjeev Gupta
+65 98551208     http://www.linkedin.com/in/ghane



On Tue, May 25, 2010 at 23:09, Olson, Arthur David (NIH/NCI) [E]
 wrote:

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 at rediffmail.com]
Sent: Tuesday, May 25, 2010 3:36
To: tz at 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,





 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jaakko.hyvatti at foreca.com  Wed May 26 02:29:15 2010
From: jaakko.hyvatti at foreca.com (=?ISO-8859-15?Q?Jaakko_Hyv=E4tti?=)
Date: Wed, 26 May 2010 05:29:15 +0300 (EEST)
Subject: FW: Timezone option
In-Reply-To: 
References: <996D816825CFEA469870126E9050D3F0E9206049@NIHMLBX11.nih.gov>  
Message-ID: 


Hi,

You could create a dynamic library that replaces necessary system calls, 
like calls to time() or gettimeofday(), and link it or load it to your 
application with LD_LIBRARY_PRELOAD environment variable.  libc versions 
of these syscalls are weak symbols and user libraries override them.

Jaakko


> From: honey bajaj [mailto:honeybajaj1 at rediffmail.com]
> Sent: Tuesday, May 25, 2010 3:36
> To: tz at 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,


-- 
Foreca Ltd                                           Jaakko.Hyvatti at foreca.com
Tammasaarenkatu 5, FI-00180 Helsinki, Finland        http://www.foreca.com