help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Timezone change in US


From: Eli Zaretskii
Subject: Re: Timezone change in US
Date: Fri, 16 Mar 2007 15:11:54 +0200

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]