GNU bug report logs - #11281
DST has not effect on windows XP when system DST adjustment is disabled

Previous Next

Full log

View this message in rfc822 format

From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11281 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: bug#11281: DST has not effect on windows XP when system DST adjustment is disabled
Date: Mon, 26 May 2025 00:08:23 +0900

On Sun, 25 May 2025 22:13:26 +0900,
Eli Zaretskii wrote:
> 
> > Date: Sun, 25 May 2025 21:03:43 +0900
> > From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> > Cc: 11281 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> > 
> > > Thanks.  Volunteers are welcome to investigate how MSVCRT works and
> > > why this sometimes causes incorrect results, because I've exhausted my
> > > knowledge of this dark corner.
> > 
> > I've found the fix.
> > I wrote tiny test program.
> > 
> > 
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <time.h>
> > 
> > static void show_globals () {
> >   printf("_daylight = %d\n" , _daylight );
> >   printf("_timezone = %ld\n", _timezone );
> >   printf("_tzname[0] = %s\n", _tzname[0]);
> >   printf("_dstbias = %d\n\n", _dstbias );
> > }
> > 
> > int main(void) {
> >   putenv("TZ=JST-9");
> >   _tzset();
> >   printf("JST-9\n");
> >   show_globals();
> > 
> >   putenv("TZ=est5edt");
> >   _tzset();
> >   printf("est5edt\n");
> >   show_globals();
> > 
> >   putenv("TZ=");
> >   _tzset();
> >   printf("System timezone\n");
> >   show_globals();
> > 
> >   putenv("TZ=est5edt");
> >   _tzset();
> >   printf("est5edt (2nd)\n");
> >   show_globals();
> > 
> >   return 0;
> > }
> > 
> > 
> > Result is here.
> > 
> > > JST-9
> > > _daylight = 0
> > > _timezone = -32400
> > > _tzname[0] = JST
> > > _dstbias = -3600
> 
> Isn't this result strange?  If a timezone has no DST, why is _dstbias
> not zero?

I feel it is strange, too.  My understanding is that tzset does not
touch _dstbias when timezone is specified by TZ environmental variable
and it is the bug.  However when _daylight is zero, _dstbias value is
not used and the issue doesn't become prominent.  Please see the
result of 2nd est5edt, where _dstbias is zero and _daylight is
non-zero, which causes the issue.  I guess the first -3600 is probably
initial value because Microsoft says that initial values are for
"PST8PDT".

> > > est5edt
> > > _daylight = 101
> > > _timezone = 18000
> > > _tzname[0] = est
> > > _dstbias = -3600
> > >
> > > System timezone
> > > _daylight = 0
> > > _timezone = -32400
> > > _tzname[0] = 東京 (標準時)
> > > _dstbias = 0
> > >
> > > est5edt (2nd)
> > > _daylight = 101
> > > _timezone = 18000
> > > _tzname[0] = est
> > > _dstbias = 0

> > But its value is never changed by setting timezone with TZ
> > environmental variable and affects calculation UTC offset of DST.
> > To change _dstbias value to -3600 fixes the issue.
> 
> Sorry, I don't think I understand: AFAIU, _dstbias can legitimately be
> zero in timezones that don't support DST.  If that is true, correcting
> a zero-valued _dstbias to 1 hour will cause problems, no?
> should also look at the value of _daylight, and only do the _dstbias
> correction of _daylight is zero (i.e. no DST in this timezone)?  Or
> what am I missing?

I agree with you that _dstbias should be zero when _daylight is zero.
However, as I wrote above, _dstbias should not be used when _daylight
is zero.  My emacs has set TZ to JST-9 long time and _dstbias has been
-3600 according to my test.  It has no problem till now.  So I removed
_daylight value check before posting the patch, but If you mind,
correcting _dstbias only when _daylight is *NON-ZERO* (not _daylight
is zero!) should be okay.

-- 
Kazuhiro Ito

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.