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