Agenda Bulk Scatter bug

Agenda Bulk Scatter bug

[Robert Cunningham]

for a few weeks now, and including the git commit 
af677f6d0667bacba72defeaee7e76557e68f8c8 that I last tested, the Agenda Bulk 
Scatter (BS) has had a bug whereby items it reschedules have the DATE lost.

As an example
SCHEDULED 2011-12-12

ends up as

SCHEDULED 

after BS


org-mode 7.5 did not have the problem


Cheers,

RJ Cunningham

Re: Agenda Bulk Scatter bug

[Christian Egli]

Robert Cunningham <robut@iinet.net.au> writes:

> for a few weeks now, and including the git commit 
> af677f6d0667bacba72defeaee7e76557e68f8c8 that I last tested, the Agenda Bulk 
> Scatter (BS) has had a bug whereby items it reschedules have the DATE lost.

Please, please, if you'd like to get your bug fixed, provide a detailed
bug report[1] and better yet do a git bisect[2] to track down which change
caused the regression. This will greatly increase the chances of the bug
actually getting fixed.

Thanks
Christian

Footnotes: 
[1]  http://orgmode.org/org.html#Feedback
[2]  http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

-- 
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland

Re: Agenda Bulk Scatter bug

[Carsten Dominik]

Hi, I need a few testers:  Something very strange is going on here.

When I evaluate this form

(decode-time (days-to-time (time-to-days (current-time))))


I get a date in the year 3980.  I think this used to work.
Is there anyone who has an idea what is going on here?

Thanks

- Carsten

On Jun 4, 2011, at 6:54 AM, Robert Cunningham wrote:

> for a few weeks now, and including the git commit 
> af677f6d0667bacba72defeaee7e76557e68f8c8 that I last tested, the Agenda Bulk 
> Scatter (BS) has had a bug whereby items it reschedules have the DATE lost.
> 
> As an example
> SCHEDULED 2011-12-12
> 
> ends up as
> 
> SCHEDULED 
> 
> after BS
> 
> 
> org-mode 7.5 did not have the problem
> 
> 
> Cheers,
> 
> RJ Cunningham
> 

- Carsten

Re: Agenda Bulk Scatter bug

[David Edmondson]

* carsten.dominik@gmail.com [2011-06-10 Fri 09:20]
> Hi, I need a few testers:  Something very strange is going on here.
>
> When I evaluate this form
>
> (decode-time (days-to-time (time-to-days (current-time))))
>
> I get a date in the year 3980.  I think this used to work.
> Is there anyone who has an idea what is going on here?

(decode-time (days-to-time (time-to-days (current-time))))
 => (0 0 1 10 6 3980 2 t 3600)

With "GNU Emacs 24.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of
2011-02-10 on keller, modified by Debian".

(time-to-days) returns the number of days since 0001-12-31bce, which
(days-to-time) converts into a time value. That time value is relative
to 0001-12-31bce, _not_ relative to 1970-01-01, which is what
(decode-time) is expecting.

Hence you end up 1970 years out.

Re: Agenda Bulk Scatter bug

[Achim Gratz]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> When I evaluate this form
>
> (decode-time (days-to-time (time-to-days (current-time))))
>
>
> I get a date in the year 3980.  I think this used to work.
> Is there anyone who has an idea what is going on here?

If I evaluate this form in the scratch buffer (no org-mode loaded), I get the
following backtrace:

  debug(error (error "Invalid time specification"))
  decode-time((968068 42752))
  eval((decode-time (days-to-time (time-to-days ...))))
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)

(version)
"GNU Emacs 23.2.1 (i586-suse-linux-gnu, GTK+ Version 2.22.1)
 of 2011-06-07 on build40"

(current-time)
(19954 27377 237772)
(time-to-days (current-time))
734298
(days-to-time (time-to-days (current-time)))
(968068 42752)
 ^^^^^^
this doesn't fit into a 16bit integer...


Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Agenda Bulk Scatter bug

[Nick Dokos]

Achim Gratz <Stromeko@nexgo.de> wrote:

> (version)
> "GNU Emacs 23.2.1 (i586-suse-linux-gnu, GTK+ Version 2.22.1)
>  of 2011-06-07 on build40"
> 
> (current-time)
> (19954 27377 237772)
> (time-to-days (current-time))
> 734298
> (days-to-time (time-to-days (current-time)))
> (968068 42752)
>  ^^^^^^
> this doesn't fit into a 16bit integer...
> 

That's what I thought at first too, until I read David Edmondson's mail:
He points out that decode-time assumes seconds since the Unix epoch
whereas time-to-days calculates the offset in days since early CE, hence the
calculation is off by 1970 years.

I did a git blame on time-to-days and days-to-time and nothing seems to
have changed recently, so I'd guess Carsten just misremembered.

Nick

Re: Agenda Bulk Scatter bug

[Michael Brand]

Hi Carsten

On Fri, Jun 10, 2011 at 10:20, Carsten Dominik
<carsten.dominik@gmail.com> wrote:
> When I evaluate this form
> (decode-time (days-to-time (time-to-days (current-time))))
> I get a date in the year 3980.  I think this used to work.
> Is there anyone who has an idea what is going on here?

Same here (except the "I think this used to work") on GNU Emacs 23.3.1
x86_64-apple-darwin that is 64 bit and has also the famous time_t with
64 bits. The error reported by others comes from time_t with 32 bits.
decode-time checks for overflow of time_t before either passing it to
the system call localtime(const time_t *), or giving the error.

But since it's only a mismatch of current-time with base 1970 and
time-to-days with base 1bec, is
(decode-time (days-to-time (- (time-to-days (current-time))
(time-to-days '(0 0)))))
what you need? Why the *days* function, for some rounding?

Michael

Re: Agenda Bulk Scatter bug

[Robert Cunningham]

G'day Carsten (and the others who've latched onto this issue),

When I first saw the thread dealing with decode-time ... I frankly had no idea 
how this related to the issue I'd reported. However, a few things have become 
clearer to me and perhaps what I see may help.

Here is what I see on:

GNU Emacs 23.1.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.18.0) of 2009-09-27 
on crested, modified by Debian

when evaluating in the scratch buffer:

(decode-time (days-to-time (time-to-days (current-time))))
(0 0 8 11 6 3980 3 nil 28800)

and when I use BS on my orgmode (git commit 
c4737ae48b84308e1ac201531aca392a81529974) agenda in this system and item is 
rescheduled as such:

   SCHEDULED: <3980-06-17 Tue>

Eureka! This seems to relate to what Carsten has picked up on.



in ANOTHER Emacs
GNU Emacs 23.1.50.1 (i486-pc-linux-gnu, GTK+ Version 2.12.9) of 2009-08-02 on 
radon, modified by Debian

I see this from the scratch buffer:


(decode-time (days-to-time (time-to-days (current-time))))
[NOTHING RETURNED]

with the following backtrace

Debugger entered--Lisp error: (error "Invalid time specification")
  decode-time((968069 63616))
  eval((decode-time (days-to-time (time-to-days ...))))
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp()
  call-interactively(eval-print-last-sexp nil nil)



The NOTHING returned here seems consistent with my originally reported 
rescheduling with a lost date.

The main difference between these two Emacs here is one is running on a 64 bit 
(40C date), the other a 32 bit machine (no date).

I can also report that in orgmode 7.5 (release version) there is no problem. 
My uneducated wild guess here would be that some code that somehow "patched" 
the date calculations in 7.5 has been removed or changed so as not to work.

Hope this of some help. I'm not quite in a position to do the git-bisect 
Christian suggested.



Cheers,

RJ Cunningham


On Friday 10 June 2011 16:20:42 Carsten Dominik wrote:
> Hi, I need a few testers:  Something very strange is going on here.
>
> When I evaluate this form
>
> (decode-time (days-to-time (time-to-days (current-time))))
>
>
> I get a date in the year 3980.  I think this used to work.
> Is there anyone who has an idea what is going on here?
>
> Thanks
>
> - Carsten
>
> On Jun 4, 2011, at 6:54 AM, Robert Cunningham wrote:
> > for a few weeks now, and including the git commit
> > af677f6d0667bacba72defeaee7e76557e68f8c8 that I last tested, the Agenda
> > Bulk Scatter (BS) has had a bug whereby items it reschedules have the
> > DATE lost.
> >
> > As an example
> > SCHEDULED 2011-12-12
> >
> > ends up as
> >
> > SCHEDULED
> >
> > after BS
> >
> >
> > org-mode 7.5 did not have the problem
> >
> >
> > Cheers,
> >
> > RJ Cunningham
>
> - Carsten

Re: Agenda Bulk Scatter bug

[Carsten Dominik]

Hi David,

On Jun 10, 2011, at 11:05 AM, David Edmondson wrote:

> * carsten.dominik@gmail.com [2011-06-10 Fri 09:20]
>> Hi, I need a few testers:  Something very strange is going on here.
>> 
>> When I evaluate this form
>> 
>> (decode-time (days-to-time (time-to-days (current-time))))
>> 
>> I get a date in the year 3980.  I think this used to work.
>> Is there anyone who has an idea what is going on here?
> 
> (decode-time (days-to-time (time-to-days (current-time))))
> => (0 0 1 10 6 3980 2 t 3600)
> 
> With "GNU Emacs 24.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of
> 2011-02-10 on keller, modified by Debian".
> 
> (time-to-days) returns the number of days since 0001-12-31bce, which
> (days-to-time) converts into a time value. That time value is relative
> to 0001-12-31bce, _not_ relative to 1970-01-01, which is what
> (decode-time) is expecting.
> 
> Hence you end up 1970 years out.

Thank you for the analysis - the bulk scattering
command should now again work as advertised.

- Carsten

Re: Agenda Bulk Scatter bug

[Carsten Dominik]

On Jun 14, 2011, at 10:41 AM, Carsten Dominik wrote:

> Hi David,
> 
> On Jun 10, 2011, at 11:05 AM, David Edmondson wrote:
> 
>> * carsten.dominik@gmail.com [2011-06-10 Fri 09:20]
>>> Hi, I need a few testers:  Something very strange is going on here.
>>> 
>>> When I evaluate this form
>>> 
>>> (decode-time (days-to-time (time-to-days (current-time))))
>>> 
>>> I get a date in the year 3980.  I think this used to work.
>>> Is there anyone who has an idea what is going on here?
>> 
>> (decode-time (days-to-time (time-to-days (current-time))))
>> => (0 0 1 10 6 3980 2 t 3600)
>> 
>> With "GNU Emacs 24.0.50.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of
>> 2011-02-10 on keller, modified by Debian".
>> 
>> (time-to-days) returns the number of days since 0001-12-31bce, which
>> (days-to-time) converts into a time value. That time value is relative
>> to 0001-12-31bce, _not_ relative to 1970-01-01, which is what
>> (decode-time) is expecting.
>> 
>> Hence you end up 1970 years out.
> 
> Thank you for the analysis - the bulk scattering
> command should now again work as advertised.

OK, only after the git server starts working again.

Until then, here is the patch:

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 65f37d4..b519ff2 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -8199,9 +8199,11 @@ The prefix arg is passed through to the command if possible."
                               (setq day-of-week 0)))))
                   ;; silently fail when try to replan a sexp entry
                   (condition-case nil
-                      (org-agenda-schedule nil
-                                           (days-to-time
-                                            (+ (org-today) distance)))
+                      (let* ((date (calendar-gregorian-from-absolute
+                                    (+ (org-today) distance)))
+                             (time (encode-time 0 0 0 (nth 1 date) (nth 0 date)
+                                                (nth 2 date))))
+                        (org-agenda-schedule nil time))
                     (error nil)))))))
 
      ((equal action ?f)