Timezone change in US

Timezone change in US

[Chris McMahan]

Well, it looks like I'm the first one on the list with this...

Now that the US has shifted into Daylight Savings, I've discovered
that emacs is still displaying DST in the modeline.

My OS (Windows XP) has updated currectly. The shell from which I
launch emacs (tcsh) has the correct time, and my TZ environement
variable in the shell correctly reflects the new timezone
(TZ=EST5EDT4,M3.2.0/2,M11.1.0/2)

I've possibly tracked the problem to an incorrect value returned by
the function current-time-zone, which is defined in the file
editfns.c. It is returning a value of -18000 EST, but it should be
-14400 EDT. This is defined in the file editfns.c

Does anybody have a patch for this, or is there something simple and
obvious I'm missing.

- Chris

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

Re: Timezone change in US

[Maarten Bergvelt]

In article <ulki28omg.fsf@one.dot.net>, Chris McMahan wrote:
> Now that the US has shifted into Daylight Savings, I've discovered
> that emacs is still displaying DST in the modeline.
> 
> My OS (Windows XP) has updated currectly. The shell from which I
> launch emacs (tcsh) has the correct time, and my TZ environement
> variable in the shell correctly reflects the new timezone
> (TZ=EST5EDT4,M3.2.0/2,M11.1.0/2)
> 
> I've possibly tracked the problem to an incorrect value returned by
> the function current-time-zone, which is defined in the file
> editfns.c. It is returning a value of -18000 EST, but it should be
> -14400 EDT. This is defined in the file editfns.c
> 
> Does anybody have a patch for this, or is there something simple and
> obvious I'm missing.

Does restarting emacs help?

-- 
Maarten Bergvelt		

Re: Timezone change in US

[Chris McMahan]

Sadly, no.

- Chris

Maarten Bergvelt <bergv@math.uiuc.edu> writes:

> In article <ulki28omg.fsf@one.dot.net>, Chris McMahan wrote:
>> Now that the US has shifted into Daylight Savings, I've discovered
>> that emacs is still displaying DST in the modeline.
>> 
>> My OS (Windows XP) has updated currectly. The shell from which I
>> launch emacs (tcsh) has the correct time, and my TZ environement
>> variable in the shell correctly reflects the new timezone
>> (TZ=EST5EDT4,M3.2.0/2,M11.1.0/2)
>> 
>> I've possibly tracked the problem to an incorrect value returned by
>> the function current-time-zone, which is defined in the file
>> editfns.c. It is returning a value of -18000 EST, but it should be
>> -14400 EDT. This is defined in the file editfns.c
>> 
>> Does anybody have a patch for this, or is there something simple and
>> obvious I'm missing.
>
> Does restarting emacs help?
>
> -- 
> Maarten Bergvelt		

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

Re: Timezone change in US

[Eli Zaretskii]

> From: Chris McMahan <first_initiallastname@one.dot.net>
> Date: Mon, 12 Mar 2007 10:31:35 -0500
> 
> Now that the US has shifted into Daylight Savings, I've discovered
> that emacs is still displaying DST in the modeline.

Do you mean that the time displayed in the mode line is off by one
hour?  Or do you mean something else?

If the time is off by one hour, do you see the correct time in the
lower-right corner of the task bar (in the system tray)?

> I've possibly tracked the problem to an incorrect value returned by
> the function current-time-zone, which is defined in the file
> editfns.c. It is returning a value of -18000 EST, but it should be
> -14400 EDT. This is defined in the file editfns.c

Does it help to switch to another time zone via Control Panel
(including clicking Apply), then switch back to your correct time
zone?  Also, make sure the "Automatically adjust clock for daylight
savings time" checkbox is checked.  You don't need to reboot Windows
XP for that, btw, the effect should be visible as soon as you click
Apply in the Control Panel's "Date and Time Properties".

Finally, did you try to see if the time is displayed correctly in
"emacs -Q"?

> Does anybody have a patch for this, or is there something simple and
> obvious I'm missing.

It works for me without any patches, although not in the US.  How
(with what version of which compiler) was your Emacs compiled?

Re: Timezone change in US

[Chris McMahan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chris McMahan <first_initiallastname@one.dot.net>
>> Date: Mon, 12 Mar 2007 10:31:35 -0500
>> 
>> Now that the US has shifted into Daylight Savings, I've discovered
>> that emacs is still displaying DST in the modeline.
>
> Do you mean that the time displayed in the mode line is off by one
> hour?  Or do you mean something else?

Yes, the time displayed in the modeline is off by one hour. It still
reflects the time before the change to Daylight Savings Time.

> If the time is off by one hour, do you see the correct time in the
> lower-right corner of the task bar (in the system tray)?

All other clocks (including the clock that my shell prompt displays)
are correct. I launch emacs from the tcsh shell as well, so if it's
getting the time from there then it should be correct.

>> I've possibly tracked the problem to an incorrect value returned by
>> the function current-time-zone, which is defined in the file
>> editfns.c. It is returning a value of -18000 EST, but it should be
>> -14400 EDT. This is defined in the file editfns.c
>
> Does it help to switch to another time zone via Control Panel
> (including clicking Apply), then switch back to your correct time
> zone?  Also, make sure the "Automatically adjust clock for daylight
> savings time" checkbox is checked.  You don't need to reboot Windows
> XP for that, btw, the effect should be visible as soon as you click
> Apply in the Control Panel's "Date and Time Properties".

A great suggestion, but alas to no avail. I do have the system set up
to automatically adjust for DST as well.

> Finally, did you try to see if the time is displayed correctly in
> "emacs -Q"?

Another great idea. The time is still off by 1 hour, however.

>> Does anybody have a patch for this, or is there something simple and
>> obvious I'm missing.
>
> It works for me without any patches, although not in the US.  How
> (with what version of which compiler) was your Emacs compiled?

I compiled using the latest version of MinGW on 5 March 07
GNU Emacs 22.0.95.1 (i386-mingw-nt5.1.2600) of 2007-03-05 on HY56D61

- Chris

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

Re: Timezone change in US

[James Cloos]

>>>>> "Chris" == Chris McMahan <first_initiallastname@one.dot.net> writes:

Chris> All other clocks (including the clock that my shell prompt
Chris> displays) are correct. I launch emacs from the tcsh shell as
Chris> well, so if it's getting the time from there then it should be
Chris> correct.

Probably a stupid question, but what happens if you set your TZ
variable to just 'EST5EDT'?  Or 'EST5EDT4,M3.2.0/2:00,M11.1.0/2:00'?

02:00 is the default for the time string, so this should be the same
as what you had:  'EST5EDT4,M3.2.0,M11.1.0'.  Does that work?

The 4 after EDT is also superfluous.  So each of these may be worth
a try:

EST5EDT,M3.2.0/2,M11.1.0/2
EST5EDT,M3.2.0/2:00,M11.1.0/2:00
EST5EDT,M3.2.0,M11.1.0

I just tried your TZ setting on my linux box, and it did the right
thing (matching the output of TZ=US/Eastern or TZ=America/New_York
with a current zoneinfo database).  So this is a win32 or mingw32
specific bug.  And using M3.3.0 instead of M3.2.0 has the expected
result of pushing off the DST transition one week, so the full TZ
syntax is getting properly parsed.

If you compiled emacs yourself, I'd suggest running in gdb with
a breakpoint at Fcurrent_time_zone (cf emacs/etc/DEBUG).  It is
probably the only good way to debug this.  (You could also try
adding some fprintf(3) calls in Fcurrent_time_zone and tm_diff
to see what is happening if you do not have gdb.  I'd print to
STDERR and redirect that to a file.)

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Timezone change in US

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Copyright: Copyright 2007 James Cloos
> Date: Tue, 13 Mar 2007 12:48:24 -0400
> Cc: help-gnu-emacs@gnu.org
> 
> 
> Probably a stupid question, but what happens if you set your TZ
> variable to just 'EST5EDT'?  Or 'EST5EDT4,M3.2.0/2:00,M11.1.0/2:00'?
> 
> 02:00 is the default for the time string, so this should be the same
> as what you had:  'EST5EDT4,M3.2.0,M11.1.0'.  Does that work?
> 
> The 4 after EDT is also superfluous.  So each of these may be worth
> a try:
> 
> EST5EDT,M3.2.0/2,M11.1.0/2
> EST5EDT,M3.2.0/2:00,M11.1.0/2:00
> EST5EDT,M3.2.0,M11.1.0

I don't think Windows time routines support the above syntax.
See:

   http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/HTML/_crt__tzset.asp

Maybe the problem is precisely that tcsh sets TZ to this form, which
confuses Emacs on Windows.  In that case, running Emacs from without
tcsh should solve the problem.

> I just tried your TZ setting on my linux box, and it did the right
> thing (matching the output of TZ=US/Eastern or TZ=America/New_York
> with a current zoneinfo database).

Note that this Posix syntax of TZ, and the zoneinfo database, are also
not supported by the Windows time routines.

> So this is a win32 or mingw32 specific bug.

Perhaps it is a w32 specific bug, but then why does it work for me?

Re: Timezone change in US

[James Cloos]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

>> From: James Cloos <cloos@jhcloos.com>
>> Copyright: Copyright 2007 James Cloos
>> Date: Tue, 13 Mar 2007 12:48:24 -0400
>> Cc: help-gnu-emacs@gnu.org
>> 
>> 
>> Probably a stupid question, but what happens if you set your TZ
>> variable to just 'EST5EDT'?  Or 'EST5EDT4,M3.2.0/2:00,M11.1.0/2:00'?
>> 
>> 02:00 is the default for the time string, so this should be the same
>> as what you had:  'EST5EDT4,M3.2.0,M11.1.0'.  Does that work?
>> 
>> The 4 after EDT is also superfluous.  So each of these may be worth
>> a try:
>> 
>> EST5EDT,M3.2.0/2,M11.1.0/2
>> EST5EDT,M3.2.0/2:00,M11.1.0/2:00
>> EST5EDT,M3.2.0,M11.1.0

Eli> I don't think Windows time routines support the above syntax.
Eli> See: [...]

I mis-remembered the details of an earlier discussion about the TZ
variable and win32.  However, the fact that his tcsh shows the correct
data with the full POSIX TZ syntax suggests that at least mingw32's
localtime(3) may grok said syntax.  (A quick check of tcsh's src shows
that it directly calls localtime(3), rather than using an external
app, to put the time in its prompt.)

Eli> Maybe the problem is precisely that tcsh sets TZ to this form, which
Eli> confuses Emacs on Windows.  In that case, running Emacs from without
Eli> tcsh should solve the problem.

That possibility is essentially why I suggested trying EST5EDT first.

Eli> Note that this Posix syntax of TZ, and the zoneinfo database, are also
Eli> not supported by the Windows time routines.

>> So this is a win32 or mingw32 specific bug.

Eli> Perhaps it is a w32 specific bug, but then why does it work for me?

I did jump to that conclusion based on the fact that tcsh was able to
get the correct offset and the presumption that it was also compiled
by way of mingw32.  I see in its src, however, that tcsh has native
support for compiling in VisualC++, so that is likely a false presumption.

Nonetheless, obviously tcsh's call to localtime(3) works whereas
emacs' attempt to get more detail is failing.

Even though I do not use win I am very intrigued by this¹ and am
interested in discovering what is going wrong.

One important issue is that, if win32 is simply ignoring everything
after "EDT" in his TZ, and if his install has not been updated to
reflect the new DST start/stop dates, he is seeing exactly what one
would expect:  EST rather than EDT.  Which does make it odd that
everything else (native or not) gets it right....

-JimC

1] Yes, I do in fact read time-nuts@febo.com :-/

-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

Re: Timezone change in US

[Eli Zaretskii]

> From: James Cloos <cloos@jhcloos.com>
> Cc: Eli Zaretskii <eliz@gnu.org>
> Copyright: Copyright 2007 James Cloos
> Date: Wed, 14 Mar 2007 07:42:14 -0400
> 
> Eli> I don't think Windows time routines support the above syntax.
> Eli> See: [...]
> 
> I mis-remembered the details of an earlier discussion about the TZ
> variable and win32.  However, the fact that his tcsh shows the correct
> data with the full POSIX TZ syntax suggests that at least mingw32's
> localtime(3) may grok said syntax.

AFAICS, there's no such thing as ``MinGW localtime'' (at least I
didn't find anything like it in the sources of MinGW runtime).  I
think MinGW programs use localtime from the Windows runtime.

Re: Timezone change in US

[Chris McMahan]

James Cloos <cloos@jhcloos.com> writes:


>>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: James Cloos <cloos@jhcloos.com>
>>> Copyright: Copyright 2007 James Cloos
>>> Date: Tue, 13 Mar 2007 12:48:24 -0400
>>> Cc: help-gnu-emacs@gnu.org
>>> 
>>> 
>>> Probably a stupid question, but what happens if you set your TZ
>>> variable to just 'EST5EDT'?  Or 'EST5EDT4,M3.2.0/2:00,M11.1.0/2:00'?
>>> 
>>> 02:00 is the default for the time string, so this should be the same
>>> as what you had:  'EST5EDT4,M3.2.0,M11.1.0'.  Does that work?
>>> 
>>> The 4 after EDT is also superfluous.  So each of these may be worth
>>> a try:
>>> 
>>> EST5EDT,M3.2.0/2,M11.1.0/2
>>> EST5EDT,M3.2.0/2:00,M11.1.0/2:00
>>> EST5EDT,M3.2.0,M11.1.0
>
> Eli> I don't think Windows time routines support the above syntax.
> Eli> See: [...]
>
> I mis-remembered the details of an earlier discussion about the TZ
> variable and win32.  However, the fact that his tcsh shows the correct
> data with the full POSIX TZ syntax suggests that at least mingw32's
> localtime(3) may grok said syntax.  (A quick check of tcsh's src shows
> that it directly calls localtime(3), rather than using an external
> app, to put the time in its prompt.)
>
> Eli> Maybe the problem is precisely that tcsh sets TZ to this form, which
> Eli> confuses Emacs on Windows.  In that case, running Emacs from without
> Eli> tcsh should solve the problem.
>
> That possibility is essentially why I suggested trying EST5EDT first.
>
> Eli> Note that this Posix syntax of TZ, and the zoneinfo database, are also
> Eli> not supported by the Windows time routines.

>>> So this is a win32 or mingw32 specific bug.
>
> Eli> Perhaps it is a w32 specific bug, but then why does it work for me?
>
> I did jump to that conclusion based on the fact that tcsh was able to
> get the correct offset and the presumption that it was also compiled
> by way of mingw32.  I see in its src, however, that tcsh has native
> support for compiling in VisualC++, so that is likely a false presumption.
>
> Nonetheless, obviously tcsh's call to localtime(3) works whereas
> emacs' attempt to get more detail is failing.
>
> Even though I do not use win I am very intrigued by this¹ and am
> interested in discovering what is going wrong.
>
> One important issue is that, if win32 is simply ignoring everything
> after "EDT" in his TZ, and if his install has not been updated to
> reflect the new DST start/stop dates, he is seeing exactly what one
> would expect:  EST rather than EDT.  Which does make it odd that
> everything else (native or not) gets it right....
>
> -JimC

I tried several variations. Interestingly, on following Eli's
suggestion, I launched emacs directly from the windows environment
(double-clicking on the runemacs icon) and the time was correct!

I unset the TZ variable in tcsh. The shell reflected the old (pre DST)
time, and so did emacs (no change in emacs). I set it to some odd
value, the shell showed a time 4 hours into the future, but emacs
still showed the pre DST time.

The short version here is that the TZ variable had no effect on emacs
whatsoever.

I'm getting the time displayed on my modeline from the time package,
and calling display-timer to show it.

- Chris

Re: Timezone change in US

[Chris McMahan]

Chris McMahan <first_initiallastname@one.dot.net> writes:

> James Cloos <cloos@jhcloos.com> writes:
>
>
>>>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: James Cloos <cloos@jhcloos.com>
>>>> Copyright: Copyright 2007 James Cloos
>>>> Date: Tue, 13 Mar 2007 12:48:24 -0400
>>>> Cc: help-gnu-emacs@gnu.org
>>>> 
>>>> 
>>>> Probably a stupid question, but what happens if you set your TZ
>>>> variable to just 'EST5EDT'?  Or 'EST5EDT4,M3.2.0/2:00,M11.1.0/2:00'?
>>>> 
>>>> 02:00 is the default for the time string, so this should be the same
>>>> as what you had:  'EST5EDT4,M3.2.0,M11.1.0'.  Does that work?
>>>> 
>>>> The 4 after EDT is also superfluous.  So each of these may be worth
>>>> a try:
>>>> 
>>>> EST5EDT,M3.2.0/2,M11.1.0/2
>>>> EST5EDT,M3.2.0/2:00,M11.1.0/2:00
>>>> EST5EDT,M3.2.0,M11.1.0
>>
>> Eli> I don't think Windows time routines support the above syntax.
>> Eli> See: [...]
>>
>> I mis-remembered the details of an earlier discussion about the TZ
>> variable and win32.  However, the fact that his tcsh shows the correct
>> data with the full POSIX TZ syntax suggests that at least mingw32's
>> localtime(3) may grok said syntax.  (A quick check of tcsh's src shows
>> that it directly calls localtime(3), rather than using an external
>> app, to put the time in its prompt.)
>>
>> Eli> Maybe the problem is precisely that tcsh sets TZ to this form, which
>> Eli> confuses Emacs on Windows.  In that case, running Emacs from without
>> Eli> tcsh should solve the problem.
>>
>> That possibility is essentially why I suggested trying EST5EDT first.
>>
>> Eli> Note that this Posix syntax of TZ, and the zoneinfo database, are also
>> Eli> not supported by the Windows time routines.
>
>>>> So this is a win32 or mingw32 specific bug.
>>
>> Eli> Perhaps it is a w32 specific bug, but then why does it work for me?
>>
>> I did jump to that conclusion based on the fact that tcsh was able to
>> get the correct offset and the presumption that it was also compiled
>> by way of mingw32.  I see in its src, however, that tcsh has native
>> support for compiling in VisualC++, so that is likely a false presumption.
>>
>> Nonetheless, obviously tcsh's call to localtime(3) works whereas
>> emacs' attempt to get more detail is failing.
>>
>> Even though I do not use win I am very intrigued by this¹ and am
>> interested in discovering what is going wrong.
>>
>> One important issue is that, if win32 is simply ignoring everything
>> after "EDT" in his TZ, and if his install has not been updated to
>> reflect the new DST start/stop dates, he is seeing exactly what one
>> would expect:  EST rather than EDT.  Which does make it odd that
>> everything else (native or not) gets it right....
>>
>> -JimC
>
> I tried several variations. Interestingly, on following Eli's
> suggestion, I launched emacs directly from the windows environment
> (double-clicking on the runemacs icon) and the time was correct!
>
> I unset the TZ variable in tcsh. The shell reflected the old (pre DST)
> time, and so did emacs (no change in emacs). I set it to some odd
> value, the shell showed a time 4 hours into the future, but emacs
> still showed the pre DST time.
>
> The short version here is that the TZ variable had no effect on emacs
> whatsoever.
>
> I'm getting the time displayed on my modeline from the time package,
> and calling display-timer to show it.
>
> - Chris

To follow up with some more details.

I did some more experiments with the TZ variable within my shell, and
it does have some effect on emacs. It seems that emacs ignores
everything in the TZ variable after the initial statement EST5EDT4. If
I set it to EST4EDT3, then emacs shows the change (of course so does
my shell). It seems that the time zone rules are still being hardcoded
incorrectly somewhere within my Cygwin environment (yes I've updated
my Cygwin packages :). I'm working on tracking that down.

- Chris

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

Re: Timezone change in US

[Eli Zaretskii]

> From: Chris McMahan <first_initiallastname@one.dot.net>
> Date: Wed, 14 Mar 2007 08:22:02 -0500
> 
> It seems that the time zone rules are still being hardcoded
> incorrectly somewhere within my Cygwin environment (yes I've updated
> my Cygwin packages :). I'm working on tracking that down.

Ah, Cygwin... you should have told that right away (and I should have
asked).  Cygwin and native Windows programs are subtly incompatible;
mixing them is asking for trouble.  I'm not at all surprised that the
time-zone issue handling in Cygwin and in native Windows programs is
different: they use different runtime libraries.

Anyway, why do you need to invoke Emacs from tcsh?  Emacs's usage
pattern is to start a session when your machine is powered up, and
then never to leave that session.  So I suggest to invoke Emacs from a
desktop icon, which will solve this problem as a nice side effect.

Re: Timezone change in US

[Chris McMahan]

I use cygwin to launch emacs so I can manipulate my environment
settings and such within the tcsh shell, rather than my windows
environment. This minimizes the potential collisions in application
names and paths between my unix programs and my windows programs (some
of which use unix program names for basic management).

I've been using this system for roughly 12 years now, and have had no
real problems.

As far as the TZ environment variable inside emacs, it is showing as
  TZ=EST5EDT4,M3.2.0/2,M11.1.0/2 
Which is correct for the new time zone rules. There is something in
the emacs program itself that still assuming I'm in EST, even though
the TCSH shell and MS Windows (XP) put me in EDT.

I would concur with your conclusion that Cygwin is the issue, except
that both Cygwin and Windows show the right time, while emacs does
not. This is leading me to believe that there's something in the
emacs code that is not behaving correctly. It seems to be an issue
with the current-time command in the C source code, but I've not been
able to track down the exact problem yet.

Thanks everyone for all of the help so far!!! It's not the most
significant issue, but finding the solution is half the fun for me! :)

- Chris

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chris McMahan <first_initiallastname@one.dot.net>
>> Date: Wed, 14 Mar 2007 08:22:02 -0500
>> 
>> It seems that the time zone rules are still being hardcoded
>> incorrectly somewhere within my Cygwin environment (yes I've updated
>> my Cygwin packages :). I'm working on tracking that down.
>
> Ah, Cygwin... you should have told that right away (and I should have
> asked).  Cygwin and native Windows programs are subtly incompatible;
> mixing them is asking for trouble.  I'm not at all surprised that the
> time-zone issue handling in Cygwin and in native Windows programs is
> different: they use different runtime libraries.
>
> Anyway, why do you need to invoke Emacs from tcsh?  Emacs's usage
> pattern is to start a session when your machine is powered up, and
> then never to leave that session.  So I suggest to invoke Emacs from a
> desktop icon, which will solve this problem as a nice side effect.
>
>

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

Re: Timezone change in US

[Eli Zaretskii]

> From: Chris McMahan <first_initiallastname@one.dot.net>
> Date: Thu, 15 Mar 2007 18:37:44 +0400
> 
> I use cygwin to launch emacs so I can manipulate my environment
> settings and such within the tcsh shell, rather than my windows
> environment. This minimizes the potential collisions in application
> names and paths between my unix programs and my windows programs (some
> of which use unix program names for basic management).

I'm not sure I understand the potential problems.  Can you give an
example of how starting Emacs from a Windows icon could cause trouble?

> I've been using this system for roughly 12 years now, and have had no
> real problems.

I don't doubt the fact, I'm just saying that you were lucky.  Cygwin
and native Windows programs are incompatible, so much so that I don't
see any reason to try to figure out what went wrong in this specific
case.

> As far as the TZ environment variable inside emacs, it is showing as
>   TZ=EST5EDT4,M3.2.0/2,M11.1.0/2 
> Which is correct for the new time zone rules.

But we've already established that the Windows native versions of time
functions don't grok this syntax of TZ.  I posted here a URL where the
Microsoft documentation clearly shows that.  So I think it's no
mystery anymore that the above value of TZ does not do what you
expect: the runtime functions used by Emacs simply don't support such
values of TZ.

> There is something in
> the emacs program itself that still assuming I'm in EST

That something is the code that interprets the value of TZ: it cannot
parse the `M3.2.0/2,M11.1.0/2' part, so it doesn't switch to EDT4.

> even though
> the TCSH shell and MS Windows (XP) put me in EDT.

Your tcsh is a Cygwin program, so it uses the Cygwin implementation of
the time routines, which do grok this syntax of TZ.

Re: Timezone change in US

[Chris McMahan]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Chris McMahan <first_initiallastname@one.dot.net>
>> Date: Thu, 15 Mar 2007 18:37:44 +0400
>> 
>> I use cygwin to launch emacs so I can manipulate my environment
>> settings and such within the tcsh shell, rather than my windows
>> environment. This minimizes the potential collisions in application
>> names and paths between my unix programs and my windows programs (some
>> of which use unix program names for basic management).
>
> I'm not sure I understand the potential problems.  Can you give an
> example of how starting Emacs from a Windows icon could cause trouble?

The main reason is that I'm setting up environment variables and paths
within my tcsh shell that are then used within emacs, but not within
Windows. There's probably no real compelling reason not to put them
into the Windows environment, but it's very nice to be able to just
edit the .tcshrc to make the necessary changes.

>> I've been using this system for roughly 12 years now, and have had no
>> real problems.
>
> I don't doubt the fact, I'm just saying that you were lucky.  Cygwin
> and native Windows programs are incompatible, so much so that I don't
> see any reason to try to figure out what went wrong in this specific
> case.

I think the only real problem comes in when you try to mix and match
the cygwin and windows utilities. I'm pointing my emacs installation
to use only the cygwin versions of utilities such as find, grep, ls,
awk and such, and so the incompatibilities have not been too much of
an issue for me.

>> As far as the TZ environment variable inside emacs, it is showing as
>>   TZ=EST5EDT4,M3.2.0/2,M11.1.0/2 
>> Which is correct for the new time zone rules.
>
> But we've already established that the Windows native versions of time
> functions don't grok this syntax of TZ.  I posted here a URL where the
> Microsoft documentation clearly shows that.  So I think it's no
> mystery anymore that the above value of TZ does not do what you
> expect: the runtime functions used by Emacs simply don't support such
> values of TZ.

Yes, thanks for posting that, it was helpful.

>> There is something in
>> the emacs program itself that still assuming I'm in EST
>
> That something is the code that interprets the value of TZ: it cannot
> parse the `M3.2.0/2,M11.1.0/2' part, so it doesn't switch to EDT4.

Then that may be the function to fix. It's apparently assuming that if
you're running windows, then it has to handle the TZ differently. The
problem is when you're running unix utilities such as I am, and the TZ
IS present in a unix format it can handle. Wouldn't it be better to
check the TZ variable itself for compatibilites, rather than assuming
based on the OS?

>> even though
>> the TCSH shell and MS Windows (XP) put me in EDT.
>
> Your tcsh is a Cygwin program, so it uses the Cygwin implementation of
> the time routines, which do grok this syntax of TZ.

I guess that's my basic point. Emacs should grok the TZ itself, and
make no assumptions based on the OS.

Changing my TZ environment variable to EDT4 fixed the problem in
emacs, and is also working in my shell. A less than optimal solution,
but it IS working now :)

Thanks for all of your help and patience on this. It was a good chance
to get into some emacs internals!

- Chris

-- 
     (.   .)
  =ooO=(_)=Ooo=====================================
  Chris McMahan | first_initiallastname@one.dot.net
  =================================================

Re: Timezone change in US

[Eli Zaretskii]

> From: Chris McMahan <first_initiallastname@one.dot.net>
> Date: Fri, 16 Mar 2007 08:25:01 -0400
> 
> The main reason is that I'm setting up environment variables and paths
> within my tcsh shell that are then used within emacs, but not within
> Windows. There's probably no real compelling reason not to put them
> into the Windows environment, but it's very nice to be able to just
> edit the .tcshrc to make the necessary changes.

Editing the Windows environment is as easy as editing .tcshrc, and
doesn't require restarting the shell.

> > I don't doubt the fact, I'm just saying that you were lucky.  Cygwin
> > and native Windows programs are incompatible, so much so that I don't
> > see any reason to try to figure out what went wrong in this specific
> > case.
> 
> I think the only real problem comes in when you try to mix and match
> the cygwin and windows utilities. I'm pointing my emacs installation
> to use only the cygwin versions of utilities such as find, grep, ls,
> awk and such, and so the incompatibilities have not been too much of
> an issue for me.

It is still a dangerous game.  For example, signal implementations are
incompatible, so I'd expect problems when you kill Emacs subprocesses.

> >> There is something in
> >> the emacs program itself that still assuming I'm in EST
> >
> > That something is the code that interprets the value of TZ: it cannot
> > parse the `M3.2.0/2,M11.1.0/2' part, so it doesn't switch to EDT4.
> 
> Then that may be the function to fix.

That function is part of the runtime library.  Its code is in one of
the Windows DLLs, and the sources are not available, as Windows is not
Free Software.

So, unless Someone(tm) is going to implement the whole slew of time
functions based on Windows API primitives and submit such an
implementation for inclusion in Emacs, we cannot fix what Microsoft
didn't do right.

> I guess that's my basic point. Emacs should grok the TZ itself, and
> make no assumptions based on the OS.

That'd be a formidable job, given the complexities involved in
time-related routines.  I won't hold my breath waiting for this to
happen any time soon.

Re: Timezone change in US

[Stefan Monnier]

> I think the only real problem comes in when you try to mix and match
> the cygwin and windows utilities.

Right.  And a normal build of Emacs under w32 is a "Windows utility" (even
if you build it using cygwin tools, it will not use the cygwin libraries
but the Windows libraries, so it won't understand cygwin filenames, for
instance, or cygwin TZ settings as you found out).

Now, I can't find the relevant data, so maybe you are using a Cygwin Emacs
(which would either be console-mode-only or use an X server rather than
native w32 windowing) rather than a w32 Emacs.


        Stefan

Re: Timezone change in US

[Eli Zaretskii]

> From: Chris McMahan <first_initiallastname@one.dot.net>
> Date: Wed, 14 Mar 2007 07:49:31 -0500
> 
> I tried several variations. Interestingly, on following Eli's
> suggestion, I launched emacs directly from the windows environment
> (double-clicking on the runemacs icon) and the time was correct!

So tcsh does get in the way, somehow.

> I unset the TZ variable in tcsh. The shell reflected the old (pre DST)
> time, and so did emacs (no change in emacs). I set it to some odd
> value, the shell showed a time 4 hours into the future, but emacs
> still showed the pre DST time.
> 
> The short version here is that the TZ variable had no effect on emacs
> whatsoever.

I think that's because (as your other message tells) your tcsh is a
Cygwin program, while Emacs is a native Windows program.  So variables
exported by tcsh are not necessarily visible to Emacs.  What do you
see if you type "M-x getenv RET TZ RET" inside Emacs launched from
tcsh?

FWIW, if I set TZ=EST5EDT in the Windows Command Prompt window, then
run Emacs from the same command prompt, it behaves as if I lived in
the EST5EDT time zone (display-time shows time for that time zone),
and `getenv' shows the value of TZ that I set from the command prompt.

Re: Timezone change in US

[Eli Zaretskii]

> From: Chris McMahan <first_initiallastname@one.dot.net>
> Date: Tue, 13 Mar 2007 08:28:59 -0500
> 
> Yes, the time displayed in the modeline is off by one hour. It still
> reflects the time before the change to Daylight Savings Time.
> 
> > If the time is off by one hour, do you see the correct time in the
> > lower-right corner of the task bar (in the system tray)?
> 
> All other clocks (including the clock that my shell prompt displays)
> are correct. I launch emacs from the tcsh shell as well, so if it's
> getting the time from there then it should be correct.

What happens if you run Emacs from a Command Prompt window, or from
Start->Run dialog, or by double-clicking on a desktop icon or on
runemacs.exe in Windows Explorer?  That is, what happens if you run it
from outside tcsh?

> I compiled using the latest version of MinGW on 5 March 07
> GNU Emacs 22.0.95.1 (i386-mingw-nt5.1.2600) of 2007-03-05 on HY56D61

What version of MinGW runtime do you have installed (look in the
header file _mingw.h in your MinGW include directory)?

Not that I think the MinGW runtime has anything to do with this, but
still...