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

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

[Mark Oteiza]

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.

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

[Paul Eggert]

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.

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

[Mark Oteiza]

* 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

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

[Paul Eggert]

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?

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

[W. Greenhouse]

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.

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

[Paul Eggert]

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.

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

[Mark Oteiza]

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.

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

[Mark Oteiza]

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?

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

[Paul Eggert]

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?

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

[Mark Oteiza]

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.

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

[Paul Eggert]

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.

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

[Mark Oteiza]

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.

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

[Paul Eggert]

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.

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

[Mark Oteiza]

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.

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

[Paul Eggert]

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.