emacs-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Make display-time-mode time zone configurable


From: Mark Oteiza
Subject: Re: [PATCH] Make display-time-mode time zone configurable
Date: Thu, 3 Mar 2016 00:39:04 +0000
User-agent: Mutt/1.5.24+59 (b55c6a64a07b) (2015-08-30)

On 21/02/16 at 09:27pm, Paul Eggert wrote:
> Mark Oteiza wrote:
> > On 19/02/16 at 10:02am, Paul Eggert wrote:
> > > >On 02/19/2016 09:14 AM, Mark Oteiza wrote:
> > > > > >My first thought of a use-case is simply keeping time zone in the 
> > > > > >mode
> > > > > >line the same regardless of what the system time (or local time) may 
> > > > > >be,
> > > > > >akin to not changing one's watch when travelling.
> > > >
> > > >That's easily done with (setenv "TZ" "America/Los_Angeles"), or whatever 
> > > >you
> > > >want the mode-line's time zone to be.
> > Sure, if you want to globally change the time zone in emacs and all the
> > subprocesses it spawns,
> 
> Which is the normal case. Users who want to affect Emacs but not
> subprocesses can call set-time-zone-rule instead of setenv. Admittedly we
> steer users away from that sort of thing, as it leads to confusion.

Yes, and set-time-zone-rule's docstring tells us to use something else:
format-time-string's ZONE argument being one of them.

> > which is counter to the purpose of the defcustom
> > in the first place--to expose convenient fine control of the displayed
> > time zone in display-time-mode.
> 
> I'm afraid we're starting to go in circles. I'm curious about why one would
> want to change just the mode-line's time zone, and you're responding that
> it's because one would want to change just the mode-line's time zone. :-)

You are repeatedly responding to the use case with the non-solution of
setting the time zone globally in Emacs.

> We needn't add a control knob for every Emacs behavior, only behaviors for
> which the benefit in fine-grained control outweighs the cost in confusion
> and complexity. The cost/benefit tradeoff for this will differ among users.

Sure, except it's implementing the same option that exists
in time-stamp.el, and the option is used the same way the other
display-time options (some, not all) are used. For instance, the options

display-time-format
display-time-mail-string
display-time-use-mail-icon
display-time-mail-face
display-time-24hr-format
display-time-day-and-date

exist solely to be used in display-time-string-forms.

> Expert users who need this sort of fine-grained control already have it; as
> far as I can see, nonexpert users don't need it enough to justify its
> complexity.



reply via email to

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