* [PATCH] Make display-time-mode time zone configurable
@ 2016-02-15 22:02 Mark Oteiza
2016-02-16 4:45 ` Paul Eggert
0 siblings, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2016-02-15 22:02 UTC (permalink / raw)
To: emacs-devel
* lisp/time.el (display-time-zone): New custom variable.
(display-time-string-forms): Use it.
* doc/emacs/display.texi: Mention and index display-time-zone.
* etc/NEWS: Mention display-time-zone.
---
Looking for feedback: format-time-string has new ZONE argument--would be
good if display-time-mode were able to use it.
doc/emacs/display.texi | 5 ++++-
etc/NEWS | 3 +++
lisp/time.el | 17 ++++++++++++++---
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/doc/emacs/display.texi b/doc/emacs/display.texi
index e3b2403..fafe188 100644
--- a/doc/emacs/display.texi
+++ b/doc/emacs/display.texi
@@ -1342,13 +1342,16 @@ line looks like this:
@noindent
@vindex display-time-24hr-format
+@vindex display-time-zone
Here @var{hh} and @var{mm} are the hour and minute, followed always by
@samp{am} or @samp{pm}. @var{l.ll} is the average number, collected
for the last few minutes, of processes in the whole system that were
either running or ready to run (i.e., were waiting for an available
processor). (Some fields may be missing if your operating system
cannot support them.) If you prefer time display in 24-hour format,
-set the variable @code{display-time-24hr-format} to @code{t}.
+set the variable @code{display-time-24hr-format} to @code{t}. The
+time zone can be configured with @code{display-time-zone}, which
+corresponds to the @var{zone} argument of @code{format-time-string}.
@cindex mail (on mode line)
@vindex display-time-use-mail-icon
diff --git a/etc/NEWS b/etc/NEWS
index f4ea3a0..1ac1a78 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1753,6 +1753,9 @@ been obsoleted.
undocumented integer-pair format. Instead, they return a list of two
integers.
+*** New option `display-time-zone' for specifying time conversion
+in `display-time-mode'. This is used as ZONE in `format-time-string'.
+
+++
** New function `set-binary-mode' allows switching a standard stream
of the Emacs process to binary I/O mode.
diff --git a/lisp/time.el b/lisp/time.el
index e0d39b1..d5e6ee9 100644
--- a/lisp/time.el
+++ b/lisp/time.el
@@ -259,15 +259,26 @@ depend on `display-time-day-and-date' and `display-time-24hr-format'."
string)
:group 'display-time)
+(defcustom display-time-zone nil
+ "Variable specifying the time zone used in `display-time-string-forms'.
+See the function `format-time-string' for an explanation of
+its ZONE variable."
+ :type '(choice (const :tag "Emacs Local Time" nil)
+ (const :tag "Universal Time" t)
+ (const :tag "System Wall Clock Time" wall)
+ (string "Time Zone Rule"))
+ :link '(function-link format-time-string)
+ :group 'display-time)
+
(defcustom display-time-string-forms
'((if (and (not display-time-format) display-time-day-and-date)
- (format-time-string "%a %b %e " now)
+ (format-time-string "%a %b %e " now display-time-zone)
"")
(propertize
(format-time-string (or display-time-format
(if display-time-24hr-format "%H:%M" "%-I:%M%p"))
- now)
- 'help-echo (format-time-string "%a %b %e, %Y" now))
+ now display-time-zone)
+ 'help-echo (format-time-string "%a %b %e, %Y" now display-time-zone))
load
(if mail
;; Build the string every time to act on customization.
--
2.7.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-15 22:02 [PATCH] Make display-time-mode time zone configurable Mark Oteiza
@ 2016-02-16 4:45 ` Paul Eggert
2016-02-16 14:33 ` W. Greenhouse
2016-02-19 2:37 ` Mark Oteiza
0 siblings, 2 replies; 15+ messages in thread
From: Paul Eggert @ 2016-02-16 4:45 UTC (permalink / raw)
To: Mark Oteiza, emacs-devel
Mark Oteiza wrote:
> +(defcustom display-time-zone nil
> + "Variable specifying the time zone used in `display-time-string-forms'.
> +See the function `format-time-string' for an explanation of
> +its ZONE variable."
> + :type '(choice (const :tag "Emacs Local Time" nil)
> + (const :tag "Universal Time" t)
> + (const :tag "System Wall Clock Time" wall)
> + (string "Time Zone Rule"))
> + :link '(function-link format-time-string)
> + :group 'display-time)
This new defcustom seems to duplicate some or all of the existing defcustom
time-stamp-time-zone. Should there be just custom var? or if there should be
two, how should they differ in operation?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-16 4:45 ` Paul Eggert
@ 2016-02-16 14:33 ` W. Greenhouse
2016-02-16 17:11 ` Paul Eggert
2016-02-19 2:37 ` Mark Oteiza
1 sibling, 1 reply; 15+ messages in thread
From: W. Greenhouse @ 2016-02-16 14:33 UTC (permalink / raw)
To: emacs-devel-mXXj517/zsQ
Paul Eggert <eggert-764C0pRuGfqVc3sceRu5cw@public.gmane.org> writes:
> Mark Oteiza wrote:
>> +(defcustom display-time-zone nil
>> + "Variable specifying the time zone used in `display-time-string-forms'.
>> +See the function `format-time-string' for an explanation of
>> +its ZONE variable."
>> + :type '(choice (const :tag "Emacs Local Time" nil)
>> + (const :tag "Universal Time" t)
>> + (const :tag "System Wall Clock Time" wall)
>> + (string "Time Zone Rule"))
>> + :link '(function-link format-time-string)
>> + :group 'display-time)
>
> This new defcustom seems to duplicate some or all of the existing
> defcustom time-stamp-time-zone. Should there be just custom var? or if
> there should be two, how should they differ in operation?
The purpose of these seems a bit different.
`display-time' is for the user to have a wall clock in the
privacy of their own Emacs; the `time-stamp' package, as I understand,
is for adding timestamped notes to files,
which one is probably sharing with others
(and a collaborative project might have some convention
about what time zone should be used for recording activity).
So they don't really do the same job,
and it's a good idea for the user to be able to set them differently.
Also, as far as parts of Emacs that deal with time zones,
there's also `calendar-time-zone', which uses a totally different
format (offset in minutes, instead of zoneinfo-style names)!
The calendar also seems to NIH the handling of daylight saving time.
Mark submitted this patch after a conversation we had on IRC
about how, despite the recent addition of timezone support to
`format-time-string', it was still difficult without bad kludges
for me to get a local wall clock on an Emacs whose system
time had to remain UTC.
It might not be desirable for various reasons to alter the "TZ"
environment variable for Emacs, which would propagate itself to all
subprocesses run by Emacs, and it might also not be right to
change the zone with `set-time-zone-rule', which would e.g. result
in sending out emails as local time, not UTC.
Now that I understand the role of `display-time-string-forms',
I can fix the problem for myself there without Mark's proposed
defcustom, but the defcustom raises visibility a lot for others
who might have the same desired wall-clock configuration as I.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-16 14:33 ` W. Greenhouse
@ 2016-02-16 17:11 ` Paul Eggert
2016-02-19 2:32 ` Mark Oteiza
0 siblings, 1 reply; 15+ messages in thread
From: Paul Eggert @ 2016-02-16 17:11 UTC (permalink / raw)
To: W. Greenhouse; +Cc: Mark Oteiza, emacs-devel
On 02/16/2016 06:33 AM, W. Greenhouse wrote:
> Also, as far as parts of Emacs that deal with time zones, there's also
> `calendar-time-zone', which uses a totally different format (offset in
> minutes, instead of zoneinfo-style names)! The calendar also seems to
> NIH the handling of daylight saving time.
Yes, the calendar code predates the new support for time zones at the
lower level, and it suffers because of that. For example, if you had
started Emacs in Cancun last year at 2015-02-01 01:59, its calendar
would have been messed up, because Cancun changed its clocks a minute
later (a time zone change, not a daylight-saving change) and Emacs would
have cached the wrong standard time zone. Eventually we should fix this
sort of bug by having the calendar code use the new lower-level
primitives better....
> Now that I understand the role of `display-time-string-forms', I can
> fix the problem for myself there without Mark's proposed defcustom,
> but the defcustom raises visibility a lot for others who might have
> the same desired wall-clock configuration as I.
OK, how about if we wait for others to have problems that cannot be
solved via display-time-string-forms and deal with the issues that come
up then.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-16 17:11 ` Paul Eggert
@ 2016-02-19 2:32 ` Mark Oteiza
0 siblings, 0 replies; 15+ messages in thread
From: Mark Oteiza @ 2016-02-19 2:32 UTC (permalink / raw)
To: Paul Eggert; +Cc: W. Greenhouse, emacs-devel
On 16/02/16 at 09:11am, Paul Eggert wrote:
> On 02/16/2016 06:33 AM, W. Greenhouse wrote:
> > Also, as far as parts of Emacs that deal with time zones, there's also
> > `calendar-time-zone', which uses a totally different format (offset in
> > minutes, instead of zoneinfo-style names)! The calendar also seems to
> > NIH the handling of daylight saving time.
>
> Yes, the calendar code predates the new support for time zones at the lower
> level, and it suffers because of that. For example, if you had started Emacs
> in Cancun last year at 2015-02-01 01:59, its calendar would have been messed
> up, because Cancun changed its clocks a minute later (a time zone change,
> not a daylight-saving change) and Emacs would have cached the wrong standard
> time zone. Eventually we should fix this sort of bug by having the calendar
> code use the new lower-level primitives better....
>
> > Now that I understand the role of `display-time-string-forms', I can fix
> > the problem for myself there without Mark's proposed defcustom, but the
> > defcustom raises visibility a lot for others who might have the same
> > desired wall-clock configuration as I.
>
> OK, how about if we wait for others to have problems that cannot be solved
> via display-time-string-forms and deal with the issues that come up then.
Seeing how display-time-string-forms is a bucket of code, I suspect there
are few problems that cannot be solved by changing it.
I would like to see this defcustom be made into something more
manageable. For instance, assimilating its large pieces into their own
functions. I just went for a less intrusive way to implement the
ZONE feature.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-16 4:45 ` Paul Eggert
2016-02-16 14:33 ` W. Greenhouse
@ 2016-02-19 2:37 ` Mark Oteiza
2016-02-19 4:57 ` Paul Eggert
1 sibling, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2016-02-19 2:37 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
On 15/02/16 at 08:45pm, Paul Eggert wrote:
> Mark Oteiza wrote:
> > +(defcustom display-time-zone nil
> > + "Variable specifying the time zone used in `display-time-string-forms'.
> > +See the function `format-time-string' for an explanation of
> > +its ZONE variable."
> > + :type '(choice (const :tag "Emacs Local Time" nil)
> > + (const :tag "Universal Time" t)
> > + (const :tag "System Wall Clock Time" wall)
> > + (string "Time Zone Rule"))
> > + :link '(function-link format-time-string)
> > + :group 'display-time)
>
> This new defcustom seems to duplicate some or all of the existing defcustom
> time-stamp-time-zone. Should there be just custom var? or if there should be
> two, how should they differ in operation?
I suppose ideally there would just be one; however, it appears to me
that lots of time-related things are fragmented across Emacs. For
instance, setting 24hr clock in display-time has its own defcustom, but
to do the same for things that use calendarfu involves setting
calendar-time-display-form.
This patch just conveniently exposes the ZONE feature in
display-time-mode in the same way time-stamp-time-zone does in
time-stamp.el. Would it make sense to put a defcustom in (I guess)
time.el and have time-stamp.el use it?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-19 2:37 ` Mark Oteiza
@ 2016-02-19 4:57 ` Paul Eggert
2016-02-19 17:14 ` Mark Oteiza
0 siblings, 1 reply; 15+ messages in thread
From: Paul Eggert @ 2016-02-19 4:57 UTC (permalink / raw)
To: Mark Oteiza; +Cc: emacs-devel
Mark Oteiza wrote:
> lots of time-related things are fragmented across Emacs.
Yes, too fragmented. People have added individual features without knowing about
the other uses.
> This patch just conveniently exposes the ZONE feature in
> display-time-mode in the same way time-stamp-time-zone does in
> time-stamp.el. Would it make sense to put a defcustom in (I guess)
> time.el and have time-stamp.el use it?
On second thought, probably not. time-stamp.el is about time stamps in files,
where it makes sense to (for example) standardize on UTC time stamps for ease of
sharing files with people in other time zones.
The proposed display-time-zone, on the other hand, is about time stamps in the
user display. This makes less sense to me, as the user display should use
consistent time stamps and there are many other ways to display time. I suppose
the use case would be something like "Although for most purposes Emacs should
behave as if the time zone is X, the mode line should sometimes but not always
use time zone Y". Why would the user want that?
Does display-time-world address the use case you're interested in? If not, what
is display-time-world missing?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-19 4:57 ` Paul Eggert
@ 2016-02-19 17:14 ` Mark Oteiza
2016-02-19 18:02 ` Paul Eggert
0 siblings, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2016-02-19 17:14 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
On 18/02/16 at 08:57pm, Paul Eggert wrote:
> Mark Oteiza wrote:
> > lots of time-related things are fragmented across Emacs.
>
> Yes, too fragmented. People have added individual features without knowing
> about the other uses.
>
> > This patch just conveniently exposes the ZONE feature in
> > display-time-mode in the same way time-stamp-time-zone does in
> > time-stamp.el. Would it make sense to put a defcustom in (I guess)
> > time.el and have time-stamp.el use it?
>
> On second thought, probably not. time-stamp.el is about time stamps in
> files, where it makes sense to (for example) standardize on UTC time stamps
> for ease of sharing files with people in other time zones.
>
> The proposed display-time-zone, on the other hand, is about time stamps in
> the user display. This makes less sense to me, as the user display should
> use consistent time stamps and there are many other ways to display time. I
> suppose the use case would be something like "Although for most purposes
> Emacs should behave as if the time zone is X, the mode line should sometimes
> but not always use time zone Y". Why would the user want that?
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.
Alternatively, similar to standardizing on one a particular time zone in
time-stamp.el, it may also be desirable in a privacy sense to
standardize the rest of Emacs' time displays (e.g. time stamps in email
or other network connections) to another time zone but still keep the
"wall clock" (meaning display-time-mode) as local time.
> Does display-time-world address the use case you're interested in? If not,
> what is display-time-world missing?
display-time-world is a one-off popup buffer, whereas display-time-mode lives
in the mode-line, so no.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-19 17:14 ` Mark Oteiza
@ 2016-02-19 18:02 ` Paul Eggert
2016-02-22 0:45 ` Mark Oteiza
0 siblings, 1 reply; 15+ messages in thread
From: Paul Eggert @ 2016-02-19 18:02 UTC (permalink / raw)
To: Mark Oteiza; +Cc: emacs-devel
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.
> Alternatively, similar to standardizing on one a particular time zone in
> time-stamp.el, it may also be desirable in a privacy sense to
> standardize the rest of Emacs' time displays (e.g. time stamps in email
> or other network connections) to another time zone but still keep the
> "wall clock" (meaning display-time-mode) as local time.
If there's a need to use publish some other time zone for privacy
reasons, then it would make sense to add a configuration variable for
one's "public time zone", which Emacs uses for email and other uses
intended to be public, while continuing to use the current TZ-based
approach for the actual time zone. Alternatively, Emacs could add a
configuration variable for one's "private time zone", which would be
used for mode lines and for other private things, while continuing to
use TZ for the time zone announced for public uses. The former of these
two alternatives sounds more plausible to me, as users expect TZ to be
the "true" time zone.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-19 18:02 ` Paul Eggert
@ 2016-02-22 0:45 ` Mark Oteiza
2016-02-22 5:27 ` Paul Eggert
0 siblings, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2016-02-22 0:45 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
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 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.
> > Alternatively, similar to standardizing on one a particular time zone in
> > time-stamp.el, it may also be desirable in a privacy sense to
> > standardize the rest of Emacs' time displays (e.g. time stamps in email
> > or other network connections) to another time zone but still keep the
> > "wall clock" (meaning display-time-mode) as local time.
>
> If there's a need to use publish some other time zone for privacy reasons,
> then it would make sense to add a configuration variable for one's "public
> time zone", which Emacs uses for email and other uses intended to be public,
> while continuing to use the current TZ-based approach for the actual time
> zone. Alternatively, Emacs could add a configuration variable for one's
> "private time zone", which would be used for mode lines and for other
> private things, while continuing to use TZ for the time zone announced for
> public uses. The former of these two alternatives sounds more plausible to
> me, as users expect TZ to be the "true" time zone.
Perhaps. However, Emacs already has knobs for time-stamps, knobs for the
modeline, and knobs for calendar-* for the different parts of
displaying/formatting time. While the fragmentation can be painful,
I don't think the problem will be solved any time soon. There will still
be some desire to customize the time zone in different parts of Emacs.
Adding a global option will just be another layer of indirection. In
the mean time, let's expose features.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-22 0:45 ` Mark Oteiza
@ 2016-02-22 5:27 ` Paul Eggert
2016-03-03 0:39 ` Mark Oteiza
0 siblings, 1 reply; 15+ messages in thread
From: Paul Eggert @ 2016-02-22 5:27 UTC (permalink / raw)
To: Mark Oteiza; +Cc: emacs-devel
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.
> 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. :-)
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. 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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-02-22 5:27 ` Paul Eggert
@ 2016-03-03 0:39 ` Mark Oteiza
2016-03-04 0:24 ` Paul Eggert
0 siblings, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2016-03-03 0:39 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-03-03 0:39 ` Mark Oteiza
@ 2016-03-04 0:24 ` Paul Eggert
0 siblings, 0 replies; 15+ messages in thread
From: Paul Eggert @ 2016-03-04 0:24 UTC (permalink / raw)
To: emacs-devel
On 03/02/2016 04:39 PM, Mark Oteiza wrote:
>
>> 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.
Yes, we are indeed going around in circles. The problem is that I
haven't seen a real use case yet.
We already have a solution for an expert who for some reason needs a
mode line in a different time zone from the Emacs default. As I
understand it, you're asking to complicate Emacs by adding a feature to
make it easier to configure Emacs to have this unusual behavior, so that
a non-expert can more easily arrange for Emacs mode lines to be in the
"wrong" time zone. My problem is that I don't understand why a
non-expert would want to do that. And without understanding the actual
need, it's hard to see why the proposed feature's benefits would be
worth its costs.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
@ 2016-03-04 22:25 Mark Oteiza
2016-03-05 1:35 ` Paul Eggert
0 siblings, 1 reply; 15+ messages in thread
From: Mark Oteiza @ 2016-03-04 22:25 UTC (permalink / raw)
To: emacs-devel; +Cc: Paul Eggert
Paul Eggert <eggert@cs.ucla.edu> writes:
> On 03/02/2016 04:39 PM, Mark Oteiza wrote:
>>
>>> 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.
>
> Yes, we are indeed going around in circles. The problem is that I
> haven't seen a real use case yet.
To me it seems you have simply dismissed the use cases already
mentioned.
> We already have a solution for an expert who for some reason needs a
> mode line in a different time zone from the Emacs default. As I
> understand it, you're asking to complicate Emacs by adding a feature
> to make it easier to configure Emacs to have this unusual behavior, so
> that a non-expert can more easily arrange for Emacs mode lines to be
> in the "wrong" time zone. My problem is that I don't understand why a
> non-expert would want to do that. And without understanding the actual
> need, it's hard to see why the proposed feature's benefits would be
> worth its costs.
Where "wrong" simply means not the emacs default. In time-stamp.el it is
considered worthwhile having the option to standardize time stamps in a
particular non-default time zone. It is not unusual for a system to be
configured to the "wrong" time zone (perhaps UTC), and it would be nice to
have the mode line clock show the "right" time.
Changing a single option is far less annoying than changing a sprawling
sexp, so it will be easier for experts and non-experts alike. I'm not
sure how expertise is relevant.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH] Make display-time-mode time zone configurable
2016-03-04 22:25 Mark Oteiza
@ 2016-03-05 1:35 ` Paul Eggert
0 siblings, 0 replies; 15+ messages in thread
From: Paul Eggert @ 2016-03-05 1:35 UTC (permalink / raw)
To: Mark Oteiza, emacs-devel
Mark Oteiza wrote:
> Paul Eggert<eggert@cs.ucla.edu> writes:
>> >Yes, we are indeed going around in circles. The problem is that I
>> >haven't seen a real use case yet.
> To me it seems you have simply dismissed the use cases already
> mentioned.
Perhaps the problem is that we have different interpretations of the phrase "use
case". I'm looking for something an ordinary (non-expert) user might want to do.
And I'm looking for a scenario described at a reasonably high level involving
how ordinary users interact with Emacs.
> In time-stamp.el it is
> considered worthwhile having the option to standardize time stamps in a
> particular non-default time zone.
Yes, and the use case there is clear. People in different time zones might want
to work on shared files, and might want to standardize on a particular time zone
(UTC, say; or US Eastern Time) for the strings in those files, regardless of the
time zone that Emacs ordinarily uses on the people's various computers. This is
a simple, high-level scenario that easily justifies a per-file time zone.
> It is not unusual for a system to be
> configured to the "wrong" time zone (perhaps UTC), and it would be nice to
> have the mode line clock show the "right" time.
Is the use case that the underlying operating system is configured to the
"wrong" time zone and this configuration cannot be changed? But if that's the
problem, an Emacs user can easily fix it by using (setenv "TZ" ...) with the
"right" time zone. No new Emacs feature is needed for this use case.
I suppose you're thinking of some other use case, but I don't know what it is.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-03-05 1:35 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-15 22:02 [PATCH] Make display-time-mode time zone configurable Mark Oteiza
2016-02-16 4:45 ` Paul Eggert
2016-02-16 14:33 ` W. Greenhouse
2016-02-16 17:11 ` Paul Eggert
2016-02-19 2:32 ` Mark Oteiza
2016-02-19 2:37 ` Mark Oteiza
2016-02-19 4:57 ` Paul Eggert
2016-02-19 17:14 ` Mark Oteiza
2016-02-19 18:02 ` Paul Eggert
2016-02-22 0:45 ` Mark Oteiza
2016-02-22 5:27 ` Paul Eggert
2016-03-03 0:39 ` Mark Oteiza
2016-03-04 0:24 ` Paul Eggert
-- strict thread matches above, loose matches on Subject: below --
2016-03-04 22:25 Mark Oteiza
2016-03-05 1:35 ` Paul Eggert
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).