Time zone and 'lapsed under NT

Time zone and 'lapsed under NT

[Lars Magne Ingebrigtsen]

I've had reports the when doing X-Sent headers under NTEmacs and
XEmacs for NT, the time zone seems to be ignored.  Could someone
investigate what's going on here?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Time zone and 'lapsed under NT

[Toby Speight]

Lars> Lars Magne Ingebrigtsen <URL:mailto:larsi@gnus.org>

0> In <URL:news:m34sjdsv8e.fsf@quimbies.gnus.org>, Lars wrote:

Lars> I've had reports the when doing X-Sent headers under NTEmacs and
Lars> XEmacs for NT, the time zone seems to be ignored.  Could someone
Lars> investigate what's going on here?

It seems to be ignoring the local time zone (it takes account of the
one on the message but assumes that the (current-time) is returning UT
rather than local time - or the other way around?

For me, (current-time-zone) returns '(3600 "GMT Daylight Time"); I
wonder if the zone name is causing confusion.  It's certainly a strange
identifier for BST!  The offset of 3600 is correct for me, though.

[Aside:

      (let ((tz (car (current-time-zone))))
        (format "Date: %s %s%04d" (current-time-string time)
                (if (> tz 0) "+" "-") (abs (/ tz 36))))

won't work very well for non-integral time zones - India will appear
as +0550 instead of +0530.]

The Emacs documentation doesn't describe (current-time) very well.  It
says, "the current time, as the number of seconds since 1970-01-01
00:00:00" - without specifying a time zone for that epoch...

Re: Time zone and 'lapsed under NT

[Lars Magne Ingebrigtsen]

Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

>       (let ((tz (car (current-time-zone))))
>         (format "Date: %s %s%04d" (current-time-string time)
>                 (if (> tz 0) "+" "-") (abs (/ tz 36))))
> 
> won't work very well for non-integral time zones - India will appear
> as +0550 instead of +0530.]

Yup.  Fix in Pterodactyl Gnus v0.95.

> The Emacs documentation doesn't describe (current-time) very well.  It
> says, "the current time, as the number of seconds since 1970-01-01
> 00:00:00" - without specifying a time zone for that epoch...

Hm.  Ooop -- the clock on this machine runs 12 minutes fast.  Er, uhm.

Anyway,

(current-time-string (current-time))
=> "Fri Jul  9 22:59:05 1999"

which is the local time, here, now.  (After fixing the clock.)

But what am I getting at?  Uhm -- perhaps the bug isn't in the
generating-the-Data-header part, but in the parsing part?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Time zone and 'lapsed under NT

[Toby Speight]

Lars> Lars Magne Ingebrigtsen <URL:mailto:larsi@gnus.org>

0> Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

>> The Emacs documentation doesn't describe (current-time) very well.  It
>> says, "the current time, as the number of seconds since 1970-01-01
>> 00:00:00" - without specifying a time zone for that epoch...


0> In <URL:news:m3vhbtfsh5.fsf@quimbies.gnus.org>, Lars wrote:

Lars> (current-time-string (current-time))
Lars> => "Fri Jul  9 22:59:05 1999"
Lars>
Lars> which is the local time, here, now.  (After fixing the clock.)

(current-time)
=> (14218 11870 732000)
(current-time-string '(14218 11870 732000))
=> "Mon Jul 12 19:05:18 1999"

That's local time for me, too (on NT).  What I'm not sure about is
whether the representation of (current-time) is the same on both
platforms; it's possible that it is seconds-after-local-epoch on one
platform and seconds-after-UT-epoch on the other.  If
(current-time-string) matches, you'd only see the difference if (a)
you transfer numeric times between the platforms or (b) you build a
numeric time from something other than (current-time).  We're doing
(b).  Just a theory.  Can you report what (current-time-string '(14218
11870 732000)) gives you?


Lars> But what am I getting at?  Uhm -- perhaps the bug isn't in the
Lars> generating-the-Data-header part, but in the parsing part?

I think perhaps it is:

(date-to-time "Thu, 01 Jan 1970 02:00:00 GMT")
=> (0 7200)
(date-to-time "Thu, 01 Jan 1970 02:00:00 EST")
=> (0 7200)

but:

(parse-time-string "Thu, 01 Jan 1970 02:00:00 GMT")
=> (0 0 2 1 1 1970 4 (0) 0)
(parse-time-string "Thu, 01 Jan 1970 02:00:00 EST")
=> (0 0 2 1 1 1970 4 (-18000) -18000)

So I suspect date-to-time, which is basically a wrapper around
encode-time.  encode-time is a built-in function, so if this is
broken, it's an NTEmacs bug.  BTW, I'm on GNU Emacs 20.3.1
(i386-*-nt4.0).  Checking:

(encode-time 0 0 2 1 1 1970 4 '(0) 0)
=> (0 7200)
(encode-time 0 0 2 1 1 1970 4 '(-18000) -18000)
=> (0 7200)

Looks like that's our bug.  A workaround ought to be possible, but
only by duplicating the broken functions.  I don't have the time to do
it.

P.S. Lars, could you report this to the Emacs bug team?  Ta.  I guess
you'd better include the associated documentation bug (what zone is
the epoch?), too.

Re: Time zone and 'lapsed under NT

[Toby Speight]

Toby> Toby Speight
Toby> <URL:mailto:Toby.Speight@streapadair.freeserve.co.uk>

0> In <URL:news:uu2r9yasp.fsf@lanber.cam.citrix.com>, Toby wrote:

Toby> (encode-time 0 0 2 1 1 1970 4 '(0) 0)
Toby> => (0 7200)
Toby> (encode-time 0 0 2 1 1 1970 4 '(-18000) -18000)
Toby> => (0 7200)
Toby>
Toby> Looks like that's our bug.  A workaround ought to be possible,
Toby> ...

Here's a workaround: in time-date.el, replace date-to-time with


(defun date-to-time (date)
  "Convert DATE into time."
  (condition-case ()
      (let ((time (parse-time-string date)))
        (setq time (cons (- (car time)
                            (- (or (nth 8 time) 0)
                               (or (car (current-time-zone)) 0)))
                         (cdr time)))
        (setcdr (cdr (cdr (cdr (cdr (cdr time))))) nil)
        (apply 'encode-time time))
    (error (error "Invalid date: %s" date))))


This could do with some testing in other time zones and a regression
test on non-NT platforms, though.

And you need to change article-make-date-line not to use
parse-time-string directly:


     ((eq type 'ut)
      (concat "Date: "
              (current-time-string
               (let* ((e (parse-time-string date))
                     (tm (apply 'encode-time e))
                     (ms (car tm))
                     (ls (- (cadr tm) (car (current-time-zone)))))

becomes

     ((eq type 'ut)
      (concat "Date: "
              (current-time-string
               (let* ((ms (car time))
                      (ls (- (cadr time) (car (current-time-zone)))))



Alternatively, you could make parse-time-string do the stuff I put
into date-to-time.

Re: Time zone and 'lapsed under NT

[Lars Magne Ingebrigtsen]

Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

> Here's a workaround: in time-date.el, replace date-to-time with
> 
> (defun date-to-time (date)
>   "Convert DATE into time."
>   (condition-case ()
>       (let ((time (parse-time-string date)))
>         (setq time (cons (- (car time)
>                             (- (or (nth 8 time) 0)
>                                (or (car (current-time-zone)) 0)))
>                          (cdr time)))
>         (setcdr (cdr (cdr (cdr (cdr (cdr time))))) nil)
>         (apply 'encode-time time))
>     (error (error "Invalid date: %s" date))))
> 
> This could do with some testing in other time zones and a regression
> test on non-NT platforms, though.

I don't think this will work correctly on non-NT platforms...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Time zone and 'lapsed under NT

[Lars Magne Ingebrigtsen]

Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

> (current-time)
> => (14218 11870 732000)
> (current-time-string '(14218 11870 732000))
> => "Mon Jul 12 19:05:18 1999"
> 
> That's local time for me, too (on NT).  What I'm not sure about is
> whether the representation of (current-time) is the same on both
> platforms; it's possible that it is seconds-after-local-epoch on one
> platform and seconds-after-UT-epoch on the other.  If
> (current-time-string) matches, you'd only see the difference if (a)
> you transfer numeric times between the platforms or (b) you build a
> numeric time from something other than (current-time).  We're doing
> (b).  Just a theory.  Can you report what (current-time-string '(14218
> 11870 732000)) gives you?

(current-time-string '(14218 11870 732000))
=> "Mon Jul 12 20:05:18 1999"

Ick.

> P.S. Lars, could you report this to the Emacs bug team?  Ta.  I guess
> you'd better include the associated documentation bug (what zone is
> the epoch?), too.

Uhm, ah...  I forget.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Time zone and 'lapsed under NT

[Toby Speight]

Lars> Lars Magne Ingebrigtsen <URL:mailto:larsi@gnus.org>

0> Toby Speight <Toby.Speight@streapadair.freeserve.co.uk> writes:

>> The Emacs documentation doesn't describe (current-time) very well.  It
>> says, "the current time, as the number of seconds since 1970-01-01
>> 00:00:00" - without specifying a time zone for that epoch...


0> In <URL:news:m3vhbtfsh5.fsf@quimbies.gnus.org>, Lars wrote:

Lars> (current-time-string (current-time))
Lars> => "Fri Jul  9 22:59:05 1999"
Lars>
Lars> which is the local time, here, now.  (After fixing the clock.)

(current-time)
=> (14218 11870 732000)
(current-time-string '(14218 11870 732000))
=> "Mon Jul 12 19:05:18 1999"

That's local time for me, too (on NT).  What I'm not sure about is
whether the representation of (current-time) is the same on both
platforms; it's possible that it is seconds-after-local-epoch on one
platform and seconds-after-UT-epoch on the other.  If
(current-time-string) matches, you'd only see the difference if (a)
you transfer numeric times between the platforms or (b) you build a
numeric time from something other than (current-time).  We're doing
(b).  Just a theory.  Can you report what (current-time-string '(14218
11870 732000)) gives you?


Lars> But what am I getting at?  Uhm -- perhaps the bug isn't in the
Lars> generating-the-Data-header part, but in the parsing part?

I think perhaps it is:

(date-to-time "Thu, 01 Jan 1970 02:00:00 GMT")
=> (0 7200)
(date-to-time "Thu, 01 Jan 1970 02:00:00 EST")
=> (0 7200)

but:

(parse-time-string "Thu, 01 Jan 1970 02:00:00 GMT")
=> (0 0 2 1 1 1970 4 (0) 0)
(parse-time-string "Thu, 01 Jan 1970 02:00:00 EST")
=> (0 0 2 1 1 1970 4 (-18000) -18000)

So I suspect date-to-time, which is basically a wrapper around
encode-time.  encode-time is a built-in function, so if this is
broken, it's an NTEmacs bug.  BTW, I'm on GNU Emacs 20.3.1
(i386-*-nt4.0).  Checking:

(encode-time 0 0 2 1 1 1970 4 '(0) 0)
=> (0 7200)
(encode-time 0 0 2 1 1 1970 4 '(-18000) -18000)
=> (0 7200)

Looks like that's our bug.  A workaround ought to be possible, but
only by duplicating the broken functions.  I don't have the time to do
it.

P.S. Lars, could you report this to the Emacs bug team?  Ta.  I guess
you'd better include the associated documentation bug (what zone is
the epoch?), too.