Re: Timezone change in US

[Chris McMahan <first_initiallastname@one.dot.net>]

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