Statistics'R'Us

Statistics'R'Us

[Lars Magne Ingebrigtsen]

Remember those gnus-bug stats I posted a while ago?  Well, I've
expanded on it some, but the most fun result was the thing below.  

The numbers to the left is the clock (0-23), and the bars to the right
are the relative numbers of bug reports/responses done in each hour.
(This is just for the last half year only, though.  Couldn't get at
the full gnus-bug archives tonight.)  The hash signs are bug reports;
the asterisks are responses sent by me.  We can deduce from this that
I seem to have inverse sleep/work patterns seen in relation to typical
Gnus users.  :-)

 0h: #############################
 0h: ************************************
 1h: #############################
 1h: ***************
 2h: #######################
 2h: *******************************
 3h: ##################
 3h: ***********************
 4h: ##############
 4h: ******************************************************
 5h: ###########
 5h: **********************************************************
 6h: ############
 6h: **************************************************************
 7h: ########
 7h: ********************************************
 8h: ###############
 8h: **********************
 9h: ###################################
 9h: *************************************
10h: ##########################################################
10h: **************************************************
11h: #######################################################################
11h: ******************************************
12h: ##########################################################################
12h: ******************************
13h: #################################################################
13h: ***************************
14h: ##############################################################
14h: ********************
15h: ####################################################################
15h: ***********************************
16h: ##############################################################
16h: *****************************************
17h: #################################################################
17h: *****************
18h: #######################################################
18h: *********************************************************
19h: #################################################
19h: ********************************************************************
20h: ################################################
20h: **********************************************************************
21h: #######################################
21h: ***********************************************
22h: ################################################
22h: ******************************************************
23h: #############################
23h: ***********************************************

(Uhm -- yes, I guess I really should be doing something useful istead
of doing graphs, but the ifi modems won't speak to me today, so, uhm,
like.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Statistics'R'Us

[visigoth]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> We can deduce from this that I seem to have inverse sleep/work
> patterns seen in relation to typical Gnus users.  :-)

One might argue, rather, that you live in a different part of the
world than many Gnus users.  ;>

John.

Re: Statistics'R'Us

[Jason R. Mastaler]

visigoth@naiad.fac.cs.cmu.edu writes:
 
> > We can deduce from this that I seem to have inverse sleep/work
> > patterns seen in relation to typical Gnus users.  :-)
> 
> One might argue, rather, that you live in a different part of the
> world than many Gnus users.  ;>
 
I don't think that makes a difference.  The graphs look like they are
based on what time the messages were sent locally.  4am in norway is
early in the morning, just as it is in pittsburgh.  He still gets
credit for being a vampire.  :-)
 

Re: Statistics'R'Us

[visigoth]

jason@mastaler.com (Jason R. Mastaler) writes:

> I don't think that makes a difference.  The graphs look like they are
> based on what time the messages were sent locally.  4am in norway is
> early in the morning, just as it is in pittsburgh.  He still gets
> credit for being a vampire.  :-)

That doesn't mean that many faithful Gnus users aren't vampires.  <grin>

(So, Lars, was it based on your local time, or on the local time of
the sender?)

John.

Re: Statistics'R'Us

[Lars Magne Ingebrigtsen]

visigoth@naiad.fac.cs.cmu.edu writes:

> That doesn't mean that many faithful Gnus users aren't vampires.  <grin>
> 
> (So, Lars, was it based on your local time, or on the local time of
> the sender?)

Uhm...  I asked myself the same question two minutes after sending off
the stats, and I don't quite know.  :-)  Let's see:

(nnmail-date-to-time "21 Jan 1997 14:55:57 -0500")
=> (13028 56049)

(format-time-string "%k" '(13028 56049))
=> "16"

Uh.

(format-time-string "%d %m %y %T" '(13028 56049))
=> "21 01 97 16:04:17"

Uh.

Perhaps `nnmail-date-to-time' is buggy?

(current-time-string)
=> "Wed Jan 22 00:04:21 1997"

(current-time-string (nnmail-date-to-time (current-time-string)))
=> "Wed Jan 22 00:04:34 1997"

No, looks ok...

Uh.  Let's see.  When it's 14 at your house, it's 20 at mine.  Which
isn't 16 anywhere, except in the Atlantic ocean somewhere.

Here's the definition of `nnmail-date-to-time':

(defun nnmail-date-to-time (date)
  "Convert DATE into time."
  (condition-case ()
      (let* ((d1 (timezone-parse-date date))
	     (t1 (timezone-parse-time (aref d1 3))))
	(apply 'encode-time
	       (mapcar (lambda (el)
			 (and el (string-to-number el)))
		       (list
			(aref t1 2) (aref t1 1) (aref t1 0)
			(aref d1 2) (aref d1 1) (aref d1 0)
			(aref d1 4)))))
    ;; If we get an error, then we just return a 0 time.
    (error (list 0 0))))

What's wrong here?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Statistics'R'Us

[visigoth]

Hmm.

(nnmail-date-to-time "21 Jan 1997 14:00:00")       => (13029  4656)
(nnmail-date-to-time "21 Jan 1997 14:00:00 +0000") => (13028 52192)
(nnmail-date-to-time "21 Jan 1997 13:00:00 -0100") => (13028 48692)
(nnmail-date-to-time "21 Jan 1997 12:00:00 -0200") => (13028 45192)

Hmm.  Those numbers shouldn't be changing...  But they are, and in
increments of 3500...  I wonder...

(nnmail-date-to-time "21 Jan 1997 14:00:00 +0001") => (13028 52191)

Oho!

It looks like you are counting the timezone delta in SECONDS, and
that's just not right.  :)  One moment...

(nnmail-date-to-time "21 Jan 1997 13:00:00 -3600") => (13028 52192)

Let's see if I can get you a fix:


Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> (defun nnmail-date-to-time (date)
>   "Convert DATE into time."
>   (condition-case ()
>       (let* ((d1 (timezone-parse-date date))
> 	       (t1 (timezone-parse-time (aref d1 3)))
---insert
<              (tz (aref d1 4))
<              (tzh (substr tz 0 2))
<              (tzm (substr tz 2 4))
<              (tzs (concat (+ (* 3600 tzh) (* 60 tzm))))
---done
>)
> 	(apply 'encode-time
> 	       (mapcar (lambda (el)
> 			 (and el (string-to-number el)))
> 		       (list
> 			(aref t1 2) (aref t1 1) (aref t1 0)
> 			(aref d1 2) (aref d1 1) (aref d1 0)
---Replace the below
> 			(aref d1 4)))))
----------------------
<			tzs))))
---done replacing
>     ;; If we get an error, then we just return a 0 time.
>     (error (list 0 0))))
> 
> What's wrong here?

The above is correct, I believe, but probably not optimal.  For one
thing, I can't recall another way to turn a number into a string, and
for another, I'm working around the mapcar by doing it.

This is a nice bug to fix, BTW.  :) It must result in some interesting
date comparisons.

John.

Re: Statistics'R'Us

[Lars Magne Ingebrigtsen]

visigoth@naiad.fac.cs.cmu.edu writes:

> It looks like you are counting the timezone delta in SECONDS, and
> that's just not right.  :) 

:-)

> <              (tz (aref d1 4))
> <              (tzh (substr tz 0 2))
> <              (tzm (substr tz 2 4))
> <              (tzs (concat (+ (* 3600 tzh) (* 60 tzm))))

Uhm, ah -- there is no `substr' function, and `*' doesn't work on
strings, and `concat' doesn't work (well) on numbers.  :-)  And the
zone can be a string like "GMT" and not an hour.

But timezone can take care of all this with `timezone-zone-to-minute',
which should do the trick, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Statistics'R'Us

[visigoth]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Uhm, ah -- there is no `substr' function, and `*' doesn't work on
> strings, and `concat' doesn't work (well) on numbers.  :-)  And the
> zone can be a string like "GMT" and not an hour.

<sigh>  No one will ever accuse -me- of testing my code.

Sorry--substring, of course, and braindeadedness on my part for the other.  ;>

> But timezone can take care of all this with `timezone-zone-to-minute',
> which should do the trick, I think.

Don't forget to multiplty by 60!  ;>

John.

Re: Statistics'R'Us

[Lars Magne Ingebrigtsen]

visigoth@naiad.fac.cs.cmu.edu writes:

> > But timezone can take care of all this with `timezone-zone-to-minute',
> > which should do the trick, I think.
> 
> Don't forget to multiplty by 60!  ;>

Does `encode-time' expect the ZONE to be in seconds?  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: Statistics'R'Us

[visigoth]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Does `encode-time' expect the ZONE to be in seconds?  

Yup--that's how I was able to recognize what was going on.  Going from
one timezone to another with times that should be equivalent was
producing unix-times that were 3500 seconds off per timezone jump...
Since a timezone jump is "0100", and there a 3600 seconds in an hour,
I saw what was going on.

Oho!

Even better--I just found the documentation I had been looking for.

>From decode-time (which encode-time refers to):

> ZONE is an integer indicating the number of seconds east of Greenwich.

>From encode-time:

> This can be a string (as from `set-time-zone-rule'), or it can be a
> list (as from `current-time-zone') or an integer (as from
> `decode-time') applied without consideration for daylight savings
> time.

So--the best thing to do appears to be to take the time-zone string
and throw it in as the time zone.  The problem occurred because you
were numerifying the time-zone, which was then interpreted as seconds
from GMT.

John.

Re: Statistics'R'Us

[Lars Magne Ingebrigtsen]

visigoth@naiad.fac.cs.cmu.edu writes:

> > ZONE is an integer indicating the number of seconds east of Greenwich.

Ah.  Fix in Red Gnus v0.83.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen