Red Hat Bugzilla – Bug 2112
Pine shows wrong time zone name (realy a glibc bug)
Last modified: 2008-05-01 11:37:49 EDT
Pine shows the wrong time zone code in mail messages when If the time zone is Europe/London. It shows the time zone name as: +0100 (GMT) instead of +0100 (BST) To fix: include the file tz_bsd.c instead of tz_sv4.c in the file imap/src/osdep/unix/os_lnx.c Explanation: The problem is realy a glibc problem where the array tzname[2] is not always set correctly and the global variable daylight defined in <time.h> is also not set correctly. For the UK time zone the vcariable daylight is set to zero where it should have been set to one. Therefore the tz name is always displayd as GMT in the pine program. Most other time zones don't show this problem, so if you want to verify this, you need to set TZ=Europe/London before running pine. A similar problem exists for US/Central time zone in winter time where the tzname is displayed as ESt instead of CST if I remeber correctly. Villy
Cristian, this looks like it should definitely get fixed.
This quote really baffles me: "A similar problem exists for US/Central time zone in winter time where the tzname is displayed as ESt instead of CST if I remeber correctly." As far as I know, we don't move in winter time from EST to CST, the timezones are always the same.
Actually, the US/Central switches between CDT and EST as zdump -v US/Central will allso show. And i beleive that they do switch to daylight savings also in Chicago. When using the date command you'll see the zone names switch between CST and CDT as it should do. You can fix the time zone handling in glibc (difficult) or fix pine to do the same thing as the date command does (easy). Or both. Villy
*** Bug 923 has been marked as a duplicate of this bug. *** On a CST system (/etc/localtime -> ../usr/share/zoneinfo/US/ Central), the tzname[] vector returns "EST" instead of "CST." This problem is visible wehn sendmail-8.9.2 taps the tzname[] external for its Date: and Received: header lines. I have not yet perused pine source code to see what it does, but the behavior seems similar. Within sendmail, the files conf.h and arpadate.c define and reference "extern char *tzname[]." I have not yet found what and how sets this array. Yet, the problem seems to be withinthe LInuz setup rather than within sendmail. Thanks, igor ------- Additional Comments From igorl+rh@life.uiuc.edu 01/23/99 15:03 ------- Here's a little program (from Gregory Shapiro of Sendmail Inc.) that demonstrates the problem: #include <stdio.h> #include <time.h> main(int argc, char **argv) { time_t t = time(NULL); struct tm *lt; extern char *tzname[]; lt = localtime(&t); printf("TZ_TM_ZONE: %s\n", lt->tm_zone); printf("TZ_TZNAME: %s\n", tzname[lt->tm_isdst]); if (lt->tm_isdst > 0) printf("Fixed TZ_TZNAME: %s\n", tzname[1]); else if (lt->tm_isdst == 0) printf("Fixed TZ_TZNAME: %s\n", tzname[0]); else printf("Fixed TZ_TZNAME: Timezone not available\n"); } ------- Additional Comments From milam@uwosh.edu 03/01/99 13:17 ------- This problem also shows up in a RHL 5.2 CST/CDT machine using qmail as the MTA and pine 4.04/4.05/4.10 as the MUA. Could this be due to the glibc "enhancements?" ------- Additional Comments From jbj@redhat.com 05/15/99 18:19 ------- What version of glibc are you using? (try "rpm -q glibc") ------- Additional Comments From jbj@redhat.com 05/15/99 18:19 ------- What version of glibc are you using? (try "rpm -q glibc")
*** Bug 2671 has been marked as a duplicate of this bug. *** In RedHat Linux 6.0 (using glibc 2.1.1) occurs following error, which prevents me compiling a new kernel: [Hardware clock was set at 23:17 at the moment, /etc/localtime was link to /usr/share/zoneinfo/Europe/Helsinki, no TZ or TIMEZONE variables set] eemeli@juttu:~> date Sat May 8 20:17:03 EEST 1999 eemeli@juttu:~> uname -v #2 Sat May 8 00:46:23 8v@ 1999 ^^^ Times are incorrect and timezone given by 'uname -v' stops kernel compiling just when make tries to put compiler info to kernel.
The glibc 2.1.2 package that will be available in rawhide shortly will take care of most of these problems. Please reopen or file new reports if the new package is still causing problems.