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: Eli Zaretskii <eliz <at> gnu.org>
To: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
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: Sun, 25 May 2025 18:51:06 +0300

> Date: Mon, 26 May 2025 00:08:23 +0900
> From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> Cc: 11281 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> 
> > > > 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.

If tzset doesn't touch _dstbias, the results begin to make sense,
because it means _dstbias is left at its value determine by previous
calls, and does not necessarily correspond to the timezone set by the
call to tzset.  But if that is the case, we should correct this bug by
examining the value of TZ and assigning to _dstbias the value of
either -3600 or zero, depending on whether the value of TZ does or
doesn't specify the "DST" part.  IOW, blindly "correcting" the zero
value of _dstbias is not right; we should instead go by the DST
definition of the value in TZ.

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

I can understand this in your case, since your timezone doesn't
specify DST.  Can you show me what the GetTimeZoneInformation API
returns on your system with your default timezone?

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

See above: I think I changed my mind, and we should set _dstbias
according to the actual value of TZ, and only if TZ is indeed set
(because I think if TZ is not set, MSVCRT gets the correct value from
GetTimeZoneInformation).  Can you try that and see if it improves the
current situation?

Previous Next

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