bug#7337: 23.2; (require 'time) changes timezone

bug#7337: 23.2; (require 'time) changes timezone

[Kevin Ryde]

Doing a (require 'time) changes the `current-time-zone' to the system
default per a (set-time-zone-rule nil).  I think that loading a .el
shouldn't change the zone.  The effect can be seen from "emacs -Q"

    (let (before after)
      (set-time-zone-rule "ABC+1")
      (setq before (current-time-zone))
      (require 'time)
      (setq after  (current-time-zone))
      (list (car before) (car after)))
    => (-3600 39600)

where I expected

    => (-3600 -3600)

which is what happens if evaluated a second time, since (require 'time)
is then a no-op.

I suppose it comes from display-time-world-list probing whether the
Olson timezone names are known to the C library.  I think it should save
and restore the existing TZ the way `add-change-log-entry' and
`time-stamp-string' do.


For some of my own code lately I tried a macro to hide the details and
the unwind-protect a bit.  Perhaps a name like with-time-zone-rule or
with-temporary-time-zone-rule would match set-time-zone-rule better than
"...-TZ".

(defmacro xtide-with-TZ (tz &rest body)
  "Run BODY with `set-time-zone-rule' temporarily to TZ.
The current timezone (per `getenv' \"TZ\") is restored by an
`unwind-protect'."
  (declare (indent 1))
  `(let ((xtide-with-TZ--old (getenv "TZ")))
     (set-time-zone-rule ,tz)
     (unwind-protect
         (progn ,@body)
       (set-time-zone-rule xtide-with-TZ--old))))



In GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0)
 of 2010-05-16 on raven, modified by Debian
configured using `configure  '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.2/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.2/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.2/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=i486-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_AU
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-1-unix
  default enable-multibyte-characters: t

bug#7337: 23.2; (require 'time) changes timezone

[Stefan Monnier]

> Doing a (require 'time) changes the `current-time-zone' to the system
> default per a (set-time-zone-rule nil).  I think that loading a .el
> shouldn't change the zone.  The effect can be seen from "emacs -Q"

>     (let (before after)
>       (set-time-zone-rule "ABC+1")
>       (setq before (current-time-zone))
>       (require 'time)
>       (setq after  (current-time-zone))
>       (list (car before) (car after)))
>     => (-3600 39600)

> where I expected

>     => (-3600 -3600)

> which is what happens if evaluated a second time, since (require 'time)
> is then a no-op.

Indeed, that's a bug.

> I suppose it comes from display-time-world-list probing whether the
> Olson timezone names are known to the C library.  I think it should save
> and restore the existing TZ the way `add-change-log-entry' and
> `time-stamp-string' do.

But do those two other uses work?

> For some of my own code lately I tried a macro to hide the details and
> the unwind-protect a bit.  Perhaps a name like with-time-zone-rule or
> with-temporary-time-zone-rule would match set-time-zone-rule better than
> "...-TZ".

> (defmacro xtide-with-TZ (tz &rest body)
>   "Run BODY with `set-time-zone-rule' temporarily to TZ.
> The current timezone (per `getenv' \"TZ\") is restored by an
> `unwind-protect'."
>   (declare (indent 1))
>   `(let ((xtide-with-TZ--old (getenv "TZ")))
>      (set-time-zone-rule ,tz)
>      (unwind-protect
>          (progn ,@body)
>        (set-time-zone-rule xtide-with-TZ--old))))

And similar does this code work for you?  In my tests, (getenv "TZ")
just always returns nil.  So it seems we'd need to add a new function
time-zone-rule to get the current time-zone rule.  Or else we could
make set-time-zone-rule return the previous time-zone rule.


        Stefan

bug#7337: 23.2; (require 'time) changes timezone

[Kevin Ryde]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> But do those two other uses work?

Oh, they might be dodgy too.  I suppose set-time-zone-rule changes the C
level environ[], but the lisp `getenv' looks in the process-environment
variable, not environ[].  Does that sound right?  Should
set-time-zone-rule set TZ in process-environment?

bug#7337: 23.2; (require 'time) changes timezone

[Kevin Ryde]

I wrote:
>
> lisp `getenv' ... TZ

Perhaps it should effectively be a save-and-restore of getenv TZ, since
setenv TZ does the set-time-zone-rule (in emacs22 up).

    (let ((old (getenv "TZ")))
      (setenv "TZ" new)
      (unwind-protect
        (...)
        (setenv "TZ" old)))


Which would still lose any set-time-zone-rule that had not been
accompanied by a (setenv "TZ").  But if you've got TZ in the C environ[]
and lisp process-environment out of sync then there's probably going to
be trouble no matter what.

bug#7337: 23.2; (require 'time) changes timezone

[Lars Magne Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> And similar does this code work for you?  In my tests, (getenv "TZ")
> just always returns nil.  So it seems we'd need to add a new function
> time-zone-rule to get the current time-zone rule.  Or else we could
> make set-time-zone-rule return the previous time-zone rule.

Hm.  Would that be returning the tzname variable (as described in the
tzet manual page)?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#7337: 23.2; (require 'time) changes timezone

[Kevin Ryde]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
> Hm.  Would that be returning the tzname variable (as described in the
> tzet manual page)?

Probably not, perhaps the TZ entry the C-level environ[], if that's
essentially what set-time-zone-rule writes to.

I later changed the macro I posted to the bit below, doing a `setenv' on
restoring as well as `set-time-zone-rule'.  I suspect set-time-zone-rule
might update the lisp process-environment as well as the C environ[]
... but I'm not certain if that's right, or enough, for combinations of
save/restore and to influence the current process and/or spawned
subprocesses, etc etc.






(defmacro xtide-with-TZ (tz &rest body)
  ;; checkdoc-params: (tz body)
  "Run BODY with `set-time-zone-rule' temporarily to TZ.
The current timezone (per `getenv' \"TZ\") is restored by an
`unwind-protect'.

This doesn't work properly if a `set-time-zone-rule' has been
applied but (setenv \"TZ\") not updated accordingly.  A `setenv'
is done here so that `xtide-with-TZ' will nest successfully at
least."

  ;; This getenv and restore is similar to what add-log.el
  ;; `add-change-log-entry' and time-stamp.el `time-stamp-string' do.  In
  ;; Emacs 23.2 the initializer in `display-time-world-list' always sets
  ;; back to nil, but a restore seems a much better idea.
  ;;
  ;; (setenv "TZ") makes the new TZ visible to a nested `xtide-with-TZ' or
  ;; to `add-change-log-entry'.  As of Emacs 23.2 `set-time-zone-rule'
  ;; changes TZ in the C-level environ[], but not in the lisp level
  ;; `process-environment'.
  ;;
  ;; setenv in emacs22 up returns the value set, but in emacs21 and xemacs21
  ;; it's the whole new `process-environment', or some such, so don't depend
  ;; on the value.
  ;;
  ;; setenv in emacs22 up also calls `set-time-zone-rule' itself, but for
  ;; emacs21 and xemacs21 must do so explicitly
  ;;
  (declare (indent 1)) ;; from 'cl
  `(let ((xtide-with-TZ--old (getenv "TZ"))
         (xtide-with-TZ--new ,tz)) ;; evaluate `tz' expression only once
     (setenv "TZ" xtide-with-TZ--new)
     (set-time-zone-rule xtide-with-TZ--new)
     (unwind-protect
         (progn ,@body)
       (setenv "TZ" xtide-with-TZ--old)
       (set-time-zone-rule xtide-with-TZ--old))))

bug#7337: 23.2; (require 'time) changes timezone

[Chong Yidong]

Kevin Ryde <user42@zip.com.au> writes:

> Oh, they might be dodgy too.  I suppose set-time-zone-rule changes the C
> level environ[], but the lisp `getenv' looks in the process-environment
> variable, not environ[].  Does that sound right?  Should
> set-time-zone-rule set TZ in process-environment?

Yes, Lisp code should typically use (setenv "TZ" ...) rather than
set-time-zone-rule for this reason.  I have updated the doc of
set-time-zone-rule, and changed the users of set-time-zone-rule
accordingly.