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

Previous Next

To reply to this bug, email your comments to 11281 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Shuguang Sun <shuguang <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: DST has not effect on windows XP when system DST adjustment is
	disabled
Date: Fri, 20 Apr 2012 00:35:40 +0800

I'm using GNU Emacs 24.0.95.1 (i386-mingw-nt5.1.2600) of 2012-04-02 on
MARVIN on WindowsXP SP3. I believe the issue exists in other version
as well.

In windows,
1. If I select the time zone GMP-5 EST (East Standard Time) and  check
the enable Daylight Saving Time checkbox, the command
display-time-world in emacs can show the time of New York correctly
with DST.
2. If I select the time zone GMP-5 EST (East Standard Time) and
UNCHECK the enable Daylight Saving Time checkbox, or if I select a
time zone without DST, the command display-time-world in emacs can not
show the time of New York correctly with DST.
But actually the display-time-world-list for New York is ("EST5EDT"
"New York"), which (EST5EDT) supposes to enable the Daylight Saving
Time to show the time.

I try the following code to trace the issue:
(setq old-tz (getenv "TZ"))
(setenv "TZ" "EST+5EDT")
(message (format "%s" (getenv "TZ")))
(message (format-time-string "%A %d %B %R %Z"))
(decode-time)
(setenv "TZ" "EST+5")
(message (format "%s" (getenv "TZ")))
(message (format-time-string "%A %d %B %R %Z"))
(decode-time)
(setenv "TZ" old-tz)

The output is (Because I select a timezone without DST in windows, the
time in the outputs is no DST as I described above):
"EST+5EDT"
"Thursday 19 April 11:27 EDT"
(26 27 11 19 4 2012 4 t -18000)

"EST+5"
"Thursday 19 April 11:27 EST"
(34 27 11 19 4 2012 4 nil -18000)

(DST is t if daylight saving time is in effect,otherwise nil.from the
doc of decode-time) From the output of decode-time, it is clear that
if the TZ is set to "EST+5EDT", the DST is effect. So it is most
likely the function format-time-string can not catch this information.
But it is still weird that it DOES has effect if I enable the DST in
the Windows system.

Message #14 received at 11281 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Shuguang Sun <shuguang <at> gmail.com>
Cc: 11281 <at> debbugs.gnu.org
Subject: Re: DST has not effect on windows XP when system DST adjustment is
 disabled
Date: Fri, 01 Nov 2019 20:54:17 +0100

Shuguang Sun <shuguang <at> gmail.com> writes:

> I'm using GNU Emacs 24.0.95.1 (i386-mingw-nt5.1.2600) of 2012-04-02 on
> MARVIN on WindowsXP SP3. I believe the issue exists in other version
> as well.
>
> In windows,
> 1. If I select the time zone GMP-5 EST (East Standard Time) and  check
> the enable Daylight Saving Time checkbox, the command
> display-time-world in emacs can show the time of New York correctly
> with DST.
> 2. If I select the time zone GMP-5 EST (East Standard Time) and
> UNCHECK the enable Daylight Saving Time checkbox, or if I select a
> time zone without DST, the command display-time-world in emacs can not
> show the time of New York correctly with DST.
> But actually the display-time-world-list for New York is ("EST5EDT"
> "New York"), which (EST5EDT) supposes to enable the Daylight Saving
> Time to show the time.
>
> I try the following code to trace the issue:
> (setq old-tz (getenv "TZ"))
> (setenv "TZ" "EST+5EDT")
> (message (format "%s" (getenv "TZ")))
> (message (format-time-string "%A %d %B %R %Z"))
> (decode-time)
> (setenv "TZ" "EST+5")
> (message (format "%s" (getenv "TZ")))
> (message (format-time-string "%A %d %B %R %Z"))
> (decode-time)
> (setenv "TZ" old-tz)
>
> The output is (Because I select a timezone without DST in windows, the
> time in the outputs is no DST as I described above):
> "EST+5EDT"
> "Thursday 19 April 11:27 EDT"
> (26 27 11 19 4 2012 4 t -18000)
>
> "EST+5"
> "Thursday 19 April 11:27 EST"
> (34 27 11 19 4 2012 4 nil -18000)
>
> (DST is t if daylight saving time is in effect,otherwise nil.from the
> doc of decode-time) From the output of decode-time, it is clear that
> if the TZ is set to "EST+5EDT", the DST is effect. So it is most
> likely the function format-time-string can not catch this information.
> But it is still weird that it DOES has effect if I enable the DST in
> the Windows system.

This was reported 7 years ago, but unfortunately never got a reply at
the time.

Is this still an issue on modern versions of Emacs?

Best regards,
Stefan Kangas

Message #19 received at 11281-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Shuguang Sun <shuguang <at> gmail.com>
Cc: 11281-done <at> debbugs.gnu.org
Subject: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Fri, 7 Aug 2020 04:12:57 -0700

Stefan Kangas <stefan <at> marxist.se> writes:

> This was reported 7 years ago, but unfortunately never got a reply at
> the time.
>
> Is this still an issue on modern versions of Emacs?

More information was requested, but none was given within 39 weeks, so
I'm closing this bug.  If this is still an issue, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.

Best regards,
Stefan Kangas

Message #26 received at 11281 <at> debbugs.gnu.org (full text, mbox):

From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
To: 11281 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Tue, 20 May 2025 20:28:31 +0900

> > This was reported 7 years ago, but unfortunately never got a reply at
> > the time.
> >
> > Is this still an issue on modern versions of Emacs?
> 
> More information was requested, but none was given within 39 weeks, so
> I'm closing this bug.  If this is still an issue, please reply to this
> email (use "Reply to all" in your email client) and we can reopen the
> bug report.

As far as I tested, the problem still exists on master branch.

(let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
  ;; The result depends on whether DST is enabled on Windows timezone
  ;; setting at the time of evaluating `(setenv "TZ" nil)'.
  (setenv "TZ" nil)
  (decode-time time "est5edt"))

;; The case that DST is disabled on Windows control panel.
-> (0 0 7 20 5 2025 2 t -18000)

;; DST is enabled.
-> (0 0 8 20 5 2025 2 t -14400)

If you start emacs with TZ environmental variable specifying timzone and
never call (setenv "TZ" nil), the problem seems not to appear.

-- 
Kazuhiro Ito

Message #29 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Tue, 20 May 2025 16:22:44 +0300

> Date: Tue, 20 May 2025 20:28:31 +0900
> From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> 
> > > This was reported 7 years ago, but unfortunately never got a reply at
> > > the time.
> > >
> > > Is this still an issue on modern versions of Emacs?
> > 
> > More information was requested, but none was given within 39 weeks, so
> > I'm closing this bug.  If this is still an issue, please reply to this
> > email (use "Reply to all" in your email client) and we can reopen the
> > bug report.
> 
> As far as I tested, the problem still exists on master branch.
> 
> (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
>   ;; The result depends on whether DST is enabled on Windows timezone
>   ;; setting at the time of evaluating `(setenv "TZ" nil)'.
>   (setenv "TZ" nil)
>   (decode-time time "est5edt"))
> 
> ;; The case that DST is disabled on Windows control panel.
> -> (0 0 7 20 5 2025 2 t -18000)
> 
> ;; DST is enabled.
> -> (0 0 8 20 5 2025 2 t -14400)
> 
> If you start emacs with TZ environmental variable specifying timzone and
> never call (setenv "TZ" nil), the problem seems not to appear.

AFAIR, Windows implements the "traditional" time zones such as EST5
with built-in DST rules that are not synchronized with the actual DST
rules in New-York at this time, but are the old DST rules that
switched DST on and off at certain fixed dates (I no longer remember
the details, sorry).  So it is little wonder that by checking and
unchecking the DST correction in the Control Panel, one can easily
confuse what the time functions we use on Windows do, because they
need to convert the current correct time based on the actual time zone
to those "synthetic" time zones that no longer exist anywhere on
Earth.

My suggestion therefore is not to try such tricks in Emacs on Windows,
and not to expect that to produce results that are as accurate as on
Posix platforms.  The fact that you get the correct time when you use
DST checkbox that is identical to the DST flags of the time zone you
want to use is already a small wonder.

Bottom line: I don't think we should invest any effort into this dark
corner of Emacs on Windows.

Message #32 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Fri, 23 May 2025 17:32:15 +0900

> > (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
> >   ;; The result depends on whether DST is enabled on Windows timezone
> >   ;; setting at the time of evaluating `(setenv "TZ" nil)'.
> >   (setenv "TZ" nil)
> >   (decode-time time "est5edt"))
> > 
> > ;; The case that DST is disabled on Windows control panel.
> > -> (0 0 7 20 5 2025 2 t -18000)
> > 
> > ;; DST is enabled.
> > -> (0 0 8 20 5 2025 2 t -14400)
(snip)

> My suggestion therefore is not to try such tricks in Emacs on Windows,
> and not to expect that to produce results that are as accurate as on
> Posix platforms.

Thank you for the comment.
What do you mean by 'such tricks'?  Using traditional timezone name or
using string as a ZONE pamareter?  If the former, what is proper
string for ZONE on Windows?

-- 
Kazuhiro Ito

Message #35 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Fri, 23 May 2025 13:28:10 +0300

> Date: Fri, 23 May 2025 17:32:15 +0900
> From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> Cc: 11281 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> 
> > > (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
> > >   ;; The result depends on whether DST is enabled on Windows timezone
> > >   ;; setting at the time of evaluating `(setenv "TZ" nil)'.
> > >   (setenv "TZ" nil)
> > >   (decode-time time "est5edt"))
> > > 
> > > ;; The case that DST is disabled on Windows control panel.
> > > -> (0 0 7 20 5 2025 2 t -18000)
> > > 
> > > ;; DST is enabled.
> > > -> (0 0 8 20 5 2025 2 t -14400)
> (snip)
> 
> > My suggestion therefore is not to try such tricks in Emacs on Windows,
> > and not to expect that to produce results that are as accurate as on
> > Posix platforms.
> 
> Thank you for the comment.
> What do you mean by 'such tricks'?  Using traditional timezone name or
> using string as a ZONE pamareter?

Neither.  By "tricks" I meant unchecking the DST option in the Windows
Control Panel.

> If the former, what is proper string for ZONE on Windows?

In Emacs, the only supported TZ strings are those known to MSVCRT
time-related functions, which are of the form documented here:

  https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/tzset?view=msvc-170

Message #38 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Fri, 23 May 2025 20:23:41 +0900

> > > My suggestion therefore is not to try such tricks in Emacs on Windows,
> > > and not to expect that to produce results that are as accurate as on
> > > Posix platforms.
> > 
> > Thank you for the comment.
> > What do you mean by 'such tricks'?  Using traditional timezone name or
> > using string as a ZONE pamareter?
> 
> Neither.  By "tricks" I meant unchecking the DST option in the Windows
> Control Panel.

I live in Japan and when I set timezone to Japanese Standard Time in
the Windows Control Panel, DST option doesn't appear.  Emacs behaves
as if unchecking the DST option.  So, I think many user do the same
with unchecking the DST option.

> > If the former, what is proper string for ZONE on Windows?
> In Emacs, the only supported TZ strings are those known to MSVCRT
> time-related functions, which are of the form documented here:

Thank you for the information.

-- 
Kazuhiro Ito

Message #41 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Fri, 23 May 2025 15:42:35 +0300

> Date: Fri, 23 May 2025 20:23:41 +0900
> From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> Cc: 11281 <at> debbugs.gnu.org,
> 	stefankangas <at> gmail.com
> 
> > > > My suggestion therefore is not to try such tricks in Emacs on Windows,
> > > > and not to expect that to produce results that are as accurate as on
> > > > Posix platforms.
> > > 
> > > Thank you for the comment.
> > > What do you mean by 'such tricks'?  Using traditional timezone name or
> > > using string as a ZONE pamareter?
> > 
> > Neither.  By "tricks" I meant unchecking the DST option in the Windows
> > Control Panel.
> 
> I live in Japan and when I set timezone to Japanese Standard Time in
> the Windows Control Panel, DST option doesn't appear.  Emacs behaves
> as if unchecking the DST option.  So, I think many user do the same
> with unchecking the DST option.

I was talking about unchecking an option when it does exist and is ON
by default.

Do the problems mentioned in this bug happen when you use Emacs?  If
so, can you show a recipe which involves only Emacs, and does not
touch any TZ settings in the Windows Control Panel?

Message #44 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Fri, 23 May 2025 22:39:51 +0900

> > > > > My suggestion therefore is not to try such tricks in Emacs on Windows,
> > > > > and not to expect that to produce results that are as accurate as on
> > > > > Posix platforms.
> > > > 
> > > > Thank you for the comment.
> > > > What do you mean by 'such tricks'?  Using traditional timezone name or
> > > > using string as a ZONE pamareter?
> > > 
> > > Neither.  By "tricks" I meant unchecking the DST option in the Windows
> > > Control Panel.
> > 
> > I live in Japan and when I set timezone to Japanese Standard Time in
> > the Windows Control Panel, DST option doesn't appear.  Emacs behaves
> > as if unchecking the DST option.  So, I think many user do the same
> > with unchecking the DST option.
> 
> I was talking about unchecking an option when it does exist and is ON
> by default.

Yes, I know.  I didn't mention in the case of timezone which didn't
have DST, because I didn't expect you suggested not to disable DST.
I live without DST, so I don't know how uncommon to uncheck DST option
is.

> Do the problems mentioned in this bug happen when you use Emacs?  If
> so, can you show a recipe which involves only Emacs, and does not
> touch any TZ settings in the Windows Control Panel?

1. Set timezone to Japanese Standard Time (at UTC+09:00, Osaka,
Sapporo, Tokyo) in the Windows Control Panel.  DST option doesn't
apprear.

2. emacs -Q

3. Evaluate below code.

(let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
  (setenv "TZ" nil)
  (decode-time time "est5edt"))

Expected result: (0 0 8 20 5 2025 2 t -14400)
Actual result:   (0 0 7 20 5 2025 2 t -18000)

As far as I tested, the result depends on whether DST is enabled in
the Windows Control Panel at the time of evaluating `(setenv "TZ"
nil)'.  In the case of Windows timezone which doesn't have DST, the
result is the same with unchecking DST option.

-- 
Kazuhiro Ito

Message #47 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Fri, 23 May 2025 17:01:31 +0300

> Date: Fri, 23 May 2025 22:39:51 +0900
> From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> Cc: 11281 <at> debbugs.gnu.org,
> 	stefankangas <at> gmail.com
> 
> > Do the problems mentioned in this bug happen when you use Emacs?  If
> > so, can you show a recipe which involves only Emacs, and does not
> > touch any TZ settings in the Windows Control Panel?
> 
> 1. Set timezone to Japanese Standard Time (at UTC+09:00, Osaka,
> Sapporo, Tokyo) in the Windows Control Panel.  DST option doesn't
> apprear.
> 
> 2. emacs -Q
> 
> 3. Evaluate below code.
> 
> (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
>   (setenv "TZ" nil)
>   (decode-time time "est5edt"))
> 
> Expected result: (0 0 8 20 5 2025 2 t -14400)
> Actual result:   (0 0 7 20 5 2025 2 t -18000)
> 
> As far as I tested, the result depends on whether DST is enabled in
> the Windows Control Panel at the time of evaluating `(setenv "TZ"
> nil)'.  In the case of Windows timezone which doesn't have DST, the
> result is the same with unchecking DST option.

I think this is because MSVCRT routines assume that every time zone
has DST and changes to and from DST on certain fixed dates.  IOW, they
don't support timezones without DST and don't access the Windows
settings for the actual timezone you are using.  So the conversion to
EST5EDT is performed as if your timezone also had DST and the DST were
in effect at that date.

Message #50 received at 11281 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: kzhr <at> d1.dion.ne.jp
Cc: 11281 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Fri, 23 May 2025 17:16:12 +0300

> Cc: 11281 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> Date: Fri, 23 May 2025 17:01:31 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
> >   (setenv "TZ" nil)
> >   (decode-time time "est5edt"))
> > 
> > Expected result: (0 0 8 20 5 2025 2 t -14400)
> > Actual result:   (0 0 7 20 5 2025 2 t -18000)
> > 
> > As far as I tested, the result depends on whether DST is enabled in
> > the Windows Control Panel at the time of evaluating `(setenv "TZ"
> > nil)'.  In the case of Windows timezone which doesn't have DST, the
> > result is the same with unchecking DST option.
> 
> I think this is because MSVCRT routines assume that every time zone
> has DST and changes to and from DST on certain fixed dates.  IOW, they
> don't support timezones without DST and don't access the Windows
> settings for the actual timezone you are using.  So the conversion to
> EST5EDT is performed as if your timezone also had DST and the DST were
> in effect at that date.

Note that this:

  (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
    (setenv "TZ" "JST-9")
    (decode-time time "est5edt"))

yields the expected result.  That is, as long as you tell MSVCRT that
your current timezone doesn't use DST, the conversion is correct.
It's only when TZ is unset that MSVCRT time functions decide there is
DST, regardless of the actual timezone defined for Windows.

Message #53 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Sat, 24 May 2025 13:32:54 +0900

> > > (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
> > >   (setenv "TZ" nil)
> > >   (decode-time time "est5edt"))
> > > 
> > > Expected result: (0 0 8 20 5 2025 2 t -14400)
> > > Actual result:   (0 0 7 20 5 2025 2 t -18000)
> > > 
> > > As far as I tested, the result depends on whether DST is enabled in
> > > the Windows Control Panel at the time of evaluating `(setenv "TZ"
> > > nil)'.  In the case of Windows timezone which doesn't have DST, the
> > > result is the same with unchecking DST option.
> > 
> > I think this is because MSVCRT routines assume that every time zone
> > has DST and changes to and from DST on certain fixed dates.  IOW, they
> > don't support timezones without DST and don't access the Windows
> > settings for the actual timezone you are using.  So the conversion to
> > EST5EDT is performed as if your timezone also had DST and the DST were
> > in effect at that date.
> 
> Note that this:
> 
>   (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
>     (setenv "TZ" "JST-9")
>     (decode-time time "est5edt"))
> 
> yields the expected result.

Yes, but it is true only if you had never called `(setenv "TZ" nil)'.
Your example yields unexpected result if TZ environmental variable is
not set at starting emacs (and it is Windows's default).  Probably you
set TZ environmental variable.

;; After setting timezone without DST in the Windows Control Panel
$ TZ= emacs -Q

(let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
  (setenv "TZ" "JST-9")
  (decode-time time "est5edt"))

-> unexpected result

So, following code would fail too.

(let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
  ;; After setting timezone without DST in the Windows Control Panel
  (setenv "TZ" nil)
  (setenv "TZ" "JST-9")
  (decode-time time "est5edt"))

-> unexpected result

> That is, as long as you tell MSVCRT that
> your current timezone doesn't use DST, the conversion is correct.

As I wrote above, this problem occurs after you once call `(setenv
"TZ" nil)' under setting that system timezone is non-DST
timezone.  If you don't set TZ to nil, conversion would always
succeed.

$ TZ=est5edt emacs -Q

(let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
  (setenv "TZ" "JST-9t")
  (decode-time time "est5edt"))

-> expected result

(let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
  (setenv "TZ" "pst8pdt")
  (decode-time time "est5edt"))

-> expected result

-- 
Kazuhiro Ito

Message #56 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Sat, 24 May 2025 11:14:04 +0300

> Date: Sat, 24 May 2025 13:32:54 +0900
> From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> Cc: 11281 <at> debbugs.gnu.org,
> 	stefankangas <at> gmail.com
> 
> > Note that this:
> > 
> >   (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
> >     (setenv "TZ" "JST-9")
> >     (decode-time time "est5edt"))
> > 
> > yields the expected result.
> 
> Yes, but it is true only if you had never called `(setenv "TZ" nil)'.
> Your example yields unexpected result if TZ environmental variable is
> not set at starting emacs (and it is Windows's default).  Probably you
> set TZ environmental variable.

No, TZ is not set on my system.  But my timezone does have DST rules,
so maybe that somehow affects the results.

> ;; After setting timezone without DST in the Windows Control Panel
> $ TZ= emacs -Q
> 
> (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
>   (setenv "TZ" "JST-9")
>   (decode-time time "est5edt"))
> 
> -> unexpected result
> 
> So, following code would fail too.
> 
> (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
>   ;; After setting timezone without DST in the Windows Control Panel
>   (setenv "TZ" nil)
>   (setenv "TZ" "JST-9")
>   (decode-time time "est5edt"))
> 
> -> unexpected result
> 
> > That is, as long as you tell MSVCRT that
> > your current timezone doesn't use DST, the conversion is correct.
> 
> As I wrote above, this problem occurs after you once call `(setenv
> "TZ" nil)' under setting that system timezone is non-DST
> timezone.  If you don't set TZ to nil, conversion would always
> succeed.
> 
> $ TZ=est5edt emacs -Q
> 
> (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
>   (setenv "TZ" "JST-9t")
>   (decode-time time "est5edt"))
> 
> -> expected result
> 
> (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
>   (setenv "TZ" "pst8pdt")
>   (decode-time time "est5edt"))
> 
> -> expected result

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.

Message #59 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Sun, 25 May 2025 21:03:43 +0900

[Message part 1 (text/plain, inline)]

> > ;; After setting timezone without DST in the Windows Control Panel
> > $ TZ= emacs -Q
> > 
> > (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
> >   (setenv "TZ" "JST-9")
> >   (decode-time time "est5edt"))
> > 
> > -> unexpected result
> > 
> > So, following code would fail too.
> > 
> > (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
> >   ;; After setting timezone without DST in the Windows Control Panel
> >   (setenv "TZ" nil)
> >   (setenv "TZ" "JST-9")
> >   (decode-time time "est5edt"))
> > 
> > -> unexpected result
> > 
> > > That is, as long as you tell MSVCRT that
> > > your current timezone doesn't use DST, the conversion is correct.
> > 
> > As I wrote above, this problem occurs after you once call `(setenv
> > "TZ" nil)' under setting that system timezone is non-DST
> > timezone.  If you don't set TZ to nil, conversion would always
> > succeed.
> > 
> > $ TZ=est5edt emacs -Q
> > 
> > (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
> >   (setenv "TZ" "JST-9t")
> >   (decode-time time "est5edt"))
> > 
> > -> expected result
> > 
> > (let ((time (encode-time '(0 0 12 20 5 2025 nil nil t))))
> >   (setenv "TZ" "pst8pdt")
> >   (decode-time time "est5edt"))
> > 
> > -> expected result
> 
> 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
>
> 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

When I set timezone to system timezone without DST, _dstbias global
variable is set to 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.

There may be another issue about timezones where DST shift is not one
hour.  Wikipedia says the Lord Howe Island is so.  However I apologize
for overlooking Emacs on Windows users live there.

Tiny patch is attached.

-- 
Kazuhiro Ito

[0001-Adjust-_dstbias-value-after-tzset-on-Windows.patch (text/plain, attachment)]

Message #62 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Sun, 25 May 2025 16:13:26 +0300

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

> > 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
> 
> When I set timezone to system timezone without DST, _dstbias global
> variable is set to 0.

That's not what I see for JST-9 above.  I compiled the program here,
and I see the same result on my system for JST-9: _daylight is zero,
but _dstbias is -3600.  If I use JST-9JD, I get this:

  JST-9JDT
  _daylight = 74
  _timezone = -32400
  _tzname[0] = JST
  _dstbias = -3600

which is more reasonable.

> 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?  Maybe we
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?

> Tiny patch is attached.

Thanks.  In any case, we should redirect tzset to a Windows specific
version in w32.c, and do the correction there, instead of in
timefns.c.  In addition, mingw.org's MinGW needs to declare _dstbias
(it doesn't have the declaration in time.h).  I will do all these, but
let's first understand what these changes do and why they fix the
problem, and also how to apply them correctly without adversely
affecting timezones without DST.

Message #65 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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

Message #68 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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?

Message #71 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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

> Cc: 11281 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> Date: Sun, 25 May 2025 18:51:06 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > 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.

I think I see the problem: when TZ is defined in the environment,
tzset updates _daylight, but doesn't touch _dstbias.  So if you start
from a timezone without DST and then switch to a timezone with DST,
_dstbias stays zero, and local time is computed incorrectly.

Therefore, I suggest the patches below.  Could you please try them?

> 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

The patches below implement this, by using _daylight as the evidence
that TZ defines DST.

diff --git a/src/timefns.c b/src/timefns.c
index 4d296ff..8cf424b 100644
--- a/src/timefns.c
+++ b/src/timefns.c
@@ -189,6 +189,7 @@ emacs_localtime_rz (timezone_t tz, time_t const *t, struct tm *tm)
      display-time) are in real danger of missing timezone and DST
      changes.  Calling tzset before each localtime call fixes that.  */
   tzset ();
+  w32_fix_tzset ();
 #endif
   tm = localtime_rz (tz, t, tm);
   if (!tm && errno == ENOMEM)
@@ -306,6 +307,9 @@ tzlookup (Lisp_Object zone, bool settz)
       block_input ();
       emacs_setenv_TZ (zone_string);
       tzset ();
+#ifdef WINDOWSNT
+      w32_fix_tzset ();
+#endif
       timezone_t old_tz = local_tz;
       local_tz = new_tz;
       tzfree (old_tz);
diff --git a/src/w32.c b/src/w32.c
index 5de721a..a98a008 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -10289,6 +10289,30 @@ w32_read_registry (HKEY rootkey, Lisp_Object lkey, Lisp_Object lname)
 }
 
 
+/* mingw.org's MinGW doesn't declare _dstbias.  MinGW64 defines it as a
+   macro.  */
+#ifndef _dstbias
+__MINGW_IMPORT int _dstbias;
+#endif
+
+/* Fix a bug in MS implementation of 'tzset', to be called immediately
+   after 'tzset'.  */
+void
+w32_fix_tzset (void)
+{
+  char *tz_env = getenv ("TZ");
+
+  /* When TZ is defined in the environment, '_tzset' updates _daylight,
+     but not _dstbias.  Then if we are switching from a timezone without
+     DST to a timezone with DST, 'localtime' and friends will apply zero
+     DST bias, which is incorrect. (When TZ is not defined, '_tzset'
+     does update _dstbias using values obtained from Windows API
+     GetTimeZoneInformation.)  Here we fix that blunder by detecting
+     this situation and forcing _dstbias to be 1 hour.  */
+  if (tz_env && _daylight && !_dstbias)
+    _dstbias = -3600;
+}
+
 /* The Windows CRT functions are "optimized for speed", so they don't
    check for timezone and DST changes if they were last called less
    than 1 minute ago (see http://support.microsoft.com/kb/821231).  So
@@ -10299,6 +10323,7 @@ w32_read_registry (HKEY rootkey, Lisp_Object lkey, Lisp_Object lname)
 sys_localtime (const time_t *t)
 {
   tzset ();
+  w32_fix_tzset ();
   return localtime (t);
 }
 
diff --git a/src/w32.h b/src/w32.h
index ae3999f..9d9887e 100644
--- a/src/w32.h
+++ b/src/w32.h
@@ -234,6 +234,7 @@ #define FILE_DONT_CLOSE         0x1000
 extern int fchmodat (int, char const *, mode_t, int);
 extern int lchmod (char const *, mode_t);
 extern bool symlinks_supported (const char *);
+extern void w32_fix_tzset (void);
 
 
 /* Return total and free memory info.  */

Message #74 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Mon, 26 May 2025 22:08:22 +0900

[Message part 1 (text/plain, inline)]

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

I tried with following code.

#include <stdio.h>
#include <windows.h>

void printSYSTEMTIME (const char *name, LPSYSTEMTIME time) {
  printf("%s is %ld, %ld, %ld, %ld, %ld, %ld, %ld, %ld\n",
	 name, time->wYear, time->wMonth, time->wDayOfWeek,
	 time->wDay, time->wHour, time->wMinute, time->wSecond,
	 time->wMilliseconds);
}

int main (int argc, wchar_t* argv[]) {
  TIME_ZONE_INFORMATION timezone;

  DWORD result = GetTimeZoneInformation(&timezone);

  printf ("Return code is %d\n", result);
  printf ("Bias is %ld\n", timezone.Bias);
  wprintf (L"StandardName is %s\n", timezone.StandardName);
  printSYSTEMTIME("StandardDate", &timezone.StandardDate);
  printf ("StandardBias is %ld\n", timezone.StandardBias);
  wprintf (L"DaylightName is %s\n", timezone.DaylightName);
  printSYSTEMTIME("StandardDate", &timezone.DaylightDate);
  printf ("DaylightBias is %ld\n", timezone.DaylightBias);

  return 0;
}

result:
Return code is 0
Bias is -540
StandardName is 東京 (in utf-16-le)
StandardDate is 0, 0, 0, 0, 0, 0, 0, 0
StandardBias is 0
DaylightName is 東京 (in utf-16-le)
StandardDate is 0, 0, 0, 0, 0, 0, 0, 0
DaylightBias is 0

result on Eastern Standard Time:
Return code is 2
Bias is 300
StandardName is 東部標準時 (in utf-16-le)
StandardDate is 0, 11, 0, 1, 2, 0, 0, 0
StandardBias is 0
DaylightName is 東部夏時間 (in utf-16-le)
StandardDate is 0, 3, 0, 2, 2, 0, 0, 0
DaylightBias is -60

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

Please see attached patch.  I think we don't need to re-parse TZ value
because it is already parsed by tzset and the result is set to
_daylight variable.  In addition, I noticed there is a code that calls
tztest and needs the same workaoround on Windows in lib/time_rz.c,
however I don't know how to apply the change only on Windows.  Please
see the second patch.


--
Kazuhiro Ito

[0001-Adjust-_dstbias-value-after-tzset-on-Windows.patch (text/plain, attachment)]

[0002-lib-time_rz.c-change_env-Sample-workaround-for-Windo.patch (text/plain, attachment)]

Message #77 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Mon, 26 May 2025 23:50:51 +0900

> I think I see the problem: when TZ is defined in the environment,
> tzset updates _daylight, but doesn't touch _dstbias.  So if you start
> from a timezone without DST and then switch to a timezone with DST,
> _dstbias stays zero, and local time is computed incorrectly.
> 
> Therefore, I suggest the patches below.  Could you please try them?

As far as I tested, the issue is resolved.
Thank you!

> diff --git a/src/w32.c b/src/w32.c
> index 5de721a..a98a008 100644
> --- a/src/w32.c
> +++ b/src/w32.c
> @@ -10289,6 +10289,30 @@ w32_read_registry (HKEY rootkey, Lisp_Object lkey, Lisp_Object lname)
>  }
>  
>  
> +/* mingw.org's MinGW doesn't declare _dstbias.  MinGW64 defines it as a
> +   macro.  */
> +#ifndef _dstbias
> +__MINGW_IMPORT int _dstbias;
> +#endif
> +
> +/* Fix a bug in MS implementation of 'tzset', to be called immediately
> +   after 'tzset'.  */
> +void
> +w32_fix_tzset (void)
> +{
> +  char *tz_env = getenv ("TZ");
> +
> +  /* When TZ is defined in the environment, '_tzset' updates _daylight,
> +     but not _dstbias.  Then if we are switching from a timezone without
> +     DST to a timezone with DST, 'localtime' and friends will apply zero
> +     DST bias, which is incorrect. (When TZ is not defined, '_tzset'
> +     does update _dstbias using values obtained from Windows API
> +     GetTimeZoneInformation.)  Here we fix that blunder by detecting
> +     this situation and forcing _dstbias to be 1 hour.  */
> +  if (tz_env && _daylight && !_dstbias)
> +    _dstbias = -3600;
> +}

You wrote _dstbias should be zero when _daylight was zero, but the
patch doesn't touch _dstbias in that case.  However it whould not
cause a real problem as I wrote.

-- 
Kazuhiro Ito

Message #80 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Tue, 27 May 2025 00:02:41 +0900

> > 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?
> 
> Please see attached patch.  I think we don't need to re-parse TZ value
> because it is already parsed by tzset and the result is set to
> _daylight variable.

I posted it before reading your patch, so please ignore it

> In addition, I noticed there is a code that calls
> tztest and needs the same workaoround on Windows in lib/time_rz.c,
> however I don't know how to apply the change only on Windows.  Please
> see the second patch.

I can't reproduce the problem with your patch.  I think I was somewhat
confused.  However I'm not sure tzset call in lib/time_rz.c is really
safe.  I'll post if I found the problem not fixed.  Sorry for noise.

-- 
Kazuhiro Ito

Message #83 received at 11281 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#11281: DST has not effect on windows XP when system DST
 adjustment is disabled
Date: Mon, 26 May 2025 19:05:54 +0300

> Date: Mon, 26 May 2025 23:50:51 +0900
> From: Kazuhiro Ito <kzhr <at> d1.dion.ne.jp>
> Cc: 11281 <at> debbugs.gnu.org,
> 	stefankangas <at> gmail.com
> 
> > I think I see the problem: when TZ is defined in the environment,
> > tzset updates _daylight, but doesn't touch _dstbias.  So if you start
> > from a timezone without DST and then switch to a timezone with DST,
> > _dstbias stays zero, and local time is computed incorrectly.
> > 
> > Therefore, I suggest the patches below.  Could you please try them?
> 
> As far as I tested, the issue is resolved.
> Thank you!

Thanks, will install soon.

> > +void
> > +w32_fix_tzset (void)
> > +{
> > +  char *tz_env = getenv ("TZ");
> > +
> > +  /* When TZ is defined in the environment, '_tzset' updates _daylight,
> > +     but not _dstbias.  Then if we are switching from a timezone without
> > +     DST to a timezone with DST, 'localtime' and friends will apply zero
> > +     DST bias, which is incorrect. (When TZ is not defined, '_tzset'
> > +     does update _dstbias using values obtained from Windows API
> > +     GetTimeZoneInformation.)  Here we fix that blunder by detecting
> > +     this situation and forcing _dstbias to be 1 hour.  */
> > +  if (tz_env && _daylight && !_dstbias)
> > +    _dstbias = -3600;
> > +}
> 
> You wrote _dstbias should be zero when _daylight was zero, but the
> patch doesn't touch _dstbias in that case.  However it whould not
> cause a real problem as I wrote.

I concluded that what we need to ensure is the other way around: if
_daylight is non-zero, _dstbias must also be non-zero.  When _daylight
is zero, the value of _dstbias doesn't matter, because localtyime and
friends don't apply _dstbias in that case.

Previous Next

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