[john@math.nwu.edu] libc/863: Tzset returns EST even if TZ=CST6CDT (also with on TZ in central tz)

[Andreas Jaeger <aj@arthur.rhein-neckar.de>]

The appended bug report seems to point out a bug in the timezone
America/Chicago.  With this small test program:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#include <stdio.h>
#include <time.h>

int
main (void)
{
  char buf[256];
  struct tm *tmptr;
  time_t now;
  
  tzset ();
  now = time(NULL);
  tmptr = localtime (&now);

  printf ("tzname[0]: %s, tzname[1]: %s, daylight: %d, timezone: %d\n",
	  tzname[0], tzname[1], daylight, timezone);
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I get the following results (using glibc 2.1.100 - the report comes
from 2.0.7):
TZ=America/Chicago ./test-time 
tzname[0]: EST, tzname[1]: CDT, daylight: 1, timezone: 21600

Looking at the timezone/northamerica file it should be CST instead of
EST.  I'm adding a small test for the glibc 2.1 testsuite which fails.

Could somebody investigate this bug, please?

Thanks,
Andreas

1998-11-12  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

	* timezone/tst-timezone.c (tests): Add entry for America/Chicago
	to test for bug in PR libc/863.

--- timezone/tst-timezone.c.~1~	Mon Sep 14 23:08:18 1998
+++ timezone/tst-timezone.c	Thu Nov 12 17:54:48 1998
@@ -39,6 +39,7 @@
   { "Universal", 0, 0, {"UTC", "UTC" }},
   { "Australia/Melbourne", 1, -36000, { "EST", "EST" }},
   { "America/Sao_Paulo", 1, 10800, {"EST", "EDT" }},
+  { "America/Chicago", 1, 21600, {"CST", "CDT" }},
   { "America/Los_Angeles", 1, 28800, {"PST", "PDT" }},
   { "Asia/Tokyo", 0, -32400, {"JST", "JST" }},
   { NULL, 0, 0 }

-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

---

• To: bugs@gnu.org
• Subject: libc/863: Tzset returns EST even if TZ=CST6CDT (also with on TZ in central tz)
• From: john@math.nwu.edu
• Date: Thu, 12 Nov 1998 08:21:03 -0600
• Resent-Cc: gnats-admin@gnu.org
• Resent-Reply-To: bugs@gnu.org, john@math.nwu.edu
• Resent-To: libc-gnats@gnu.org

>Number:         863
>Category:       libc
>Synopsis:       Tzset returns EST even if TZ=CST6CDT (also with on TZ in central tz)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    libc-gnats
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Thu Nov 12 09:30:01 EST 1998
>Last-Modified:
>Originator:     John Franks
>Organization:
  John Franks
  john@math.nwu.edu
>
>Release:        libc-2.0.7
>Environment:
	
Host type: i686-pc-linux-gnu
System: Linux hopf 2.0.36 #1 Tue Oct 13 22:17:11 EDT 1998 i686 unknown
Architecture: i686

Addons: crypt linuxthreads localedata
Build CFLAGS: -O2 -m486 -fno-strength-reduce -g -DNDEBUG=1
Build CC: gcc -B$(common-objpfx)
Build shared: yes
Build profile: yes
Build omitfp: no
Stdio: libio

>Description:
There appears to be a bug in the tzset() library function
which causes problems for those of us in the central time
zone.  In particular, popular mailers like elm and pine put
the wrong time zone in their Date header.  The problem appears
in Red Hat 5.1 and 5.2, but did not occur in 5.0.  It only
manifested itself recently when daylight savings time ended. 

You can exhibit the bug by setting your timezone environment 
variable for central time and then sending mail with elm or pine.
If you are in the central time zone you don't need to set the TZ
environment variable. :(

During daylight savings time the header was correct.  This only
seems to be a problem with the central time zone.  It affects
glibc versions 2.0.7-19 to 2.0.7-29 and maybe others. The reason
this problem is rather severe is that I have been informed that
this kind of illegal date header is used as an indicator of 
forged mail or spam and discarded by some systems.

>How-To-Repeat:

   export TZ=CST6CDT;

then send mail with elm or pine.  The date header will be something like

     Date: Wed, 11 Nov 1998 22:13:37 -0600 (EST)

instead of -0600 (CST) i.e. with the correct offset, but an incorrect 
timezone.  The problem also occurs if TZ is not set and "localtime"
is a link to /usr/lib/zoneinfo/US/Central

>Fix:

A workaround is set TZ=CST6.  This will fail when DST starts again
though.
>Audit-Trail:
>Unformatted:

---