Bug: org-read-date ignores hours?

Bug: org-read-date ignores hours?

[Ag Ibragimov]

When I use (org-read-date t) and type something like "+2m" it works as expected, but for
some reason if I type something like "+2h" it returns datetime with no
changes. Expected - two hours in the future. Am I missing something?

Re: Bug: org-read-date ignores hours?

[Marco Wahl]

Hi Ag,

> When I use (org-read-date t) and type something like "+2m" it works as expected, but for
> some reason if I type something like "+2h" it returns datetime with no
> changes. Expected - two hours in the future. Am I missing something?

AFAICS your expectation is not implemented.  See function
org-read-date-get-relative.

+1 for someone trying to implement this idea.


HTH,
-- 
Marco

Re: Bug: org-read-date ignores hours?

[agzam.ibragimov]

[-- Attachment #1: Type: text/plain, Size: 948 bytes --]

While fooling around with capture templates, I have also noticed this:

(progn
  (setq org-popup-calendar-for-date-prompt t)
  (read-date t)))

When prompted, if you type something like "13:00" - it returns correct,
expected datetime.

But, if you do:

(progn
  (setq org-popup-calendar-for-date-prompt nil)
  (read-date t)))

And again, type some time value in the prompt - it returns date with no
time. This seems to be a bug.

On Thu, Oct 24, 2019 at 1:41 AM Marco Wahl <marcowahlsoft@gmail.com> wrote:

> Hi Ag,
>
> > When I use (org-read-date t) and type something like "+2m" it works as
> expected, but for
> > some reason if I type something like "+2h" it returns datetime with no
> > changes. Expected - two hours in the future. Am I missing something?
>
> AFAICS your expectation is not implemented.  See function
> org-read-date-get-relative.
>
> +1 for someone trying to implement this idea.
>
>
> HTH,
> --
> Marco
>


-- 
Regards,
Ag.

[-- Attachment #2: Type: text/html, Size: 1454 bytes --]

Re: Bug: org-read-date ignores hours?

[Marco Wahl]

agzam.ibragimov@gmail.com writes:

> While fooling around with capture templates, I have also noticed this:
>
> (progn
>   (setq org-popup-calendar-for-date-prompt t)
>   (read-date t)))
>
> When prompted, if you type something like "13:00" - it returns correct,
> expected datetime.
>
> But, if you do:
>
> (progn
>   (setq org-popup-calendar-for-date-prompt nil)
>   (read-date t)))
>
> And again, type some time value in the prompt - it returns date with no
> time. This seems to be a bug.

I can confirm this behavior with org-read-date instead of read-date.
And at first glance I also think this is a bug.

I capture this issue for someday.  But of course anyone please feel free
to fix this.

The same holds for the idea to add "h" (hours) and possibly "M"
(minutes) as a further way to specify the hour via org-read-date.


Thanks!

Re: Bug: org-read-date ignores hours?

[Bastien]

Hi,

I tried 

(progn
  (setq org-popup-calendar-for-date-prompt t)
  (org-read-date t))

(progn
  (setq org-popup-calendar-for-date-prompt nil)
  (org-read-date t))

from master and could not reproduce the problem (not having the
inserted time string taken into account).

Marco, can you reproduce the problem in master?

-- 
 Bastien

Re: Bug: org-read-date ignores hours?

[Marco Wahl]

Bastien <bzg@gnu.org> writes:

> I tried 
>
> (progn
>   (setq org-popup-calendar-for-date-prompt t)
>   (org-read-date t))
>
> (progn
>   (setq org-popup-calendar-for-date-prompt nil)
>   (org-read-date t))
>
> from master and could not reproduce the problem (not having the
> inserted time string taken into account).
>
> Marco, can you reproduce the problem in master?

I get back a date with a time in each case.

Concretely find the return values below if I do

    C-u C-x C-e 11:55 RET

after each of the two sexp's below.

(progn
  (setq org-popup-calendar-for-date-prompt t)
  (org-read-date t))

"2020-02-11 11:55"

(progn
  (setq org-popup-calendar-for-date-prompt nil)
  (org-read-date t))

"2020-02-11 11:55"

In summary I can say that this LGTM and I can't reproduce the problem.


Ciao!

Re: Bug: org-read-date ignores hours?

[Bastien]

Hi Marco,

Marco Wahl <marcowahlsoft@gmail.com> writes:

> In summary I can say that this LGTM and I can't reproduce the
> problem.

Thanks for taking the time and trouble to try reproducing it!

-- 
 Bastien