A small idea to simplify (further) time input in the date/time prompt

A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

Hi All,

the Org date/time prompt does deliver the promise in the manual that we 
"start getting annoyed by pretty
much any other way of entering a date/time out there".  It has indeed 
become so for me, as the date/time prompt is very neat.  But there is 
one place where input could be even shorter, which is time input.

Currently, time input mostly requires "hour colon minutes", thus a full 
time specification even when minutes are "00".  And "mostly" because you 
can get away with that last part if you use am/pm convention (alas, I do 
not belong to those strange corners of the world).  Besides, the colon 
is a shift-key in many common keyboard layouts (from a simple search, it 
seems to be so in British, American, US International, German, Spanish, 
and Portuguese layouts, it doesn't seem to be so for the French layout 
though).

So I'd like to suggest a simplification there, which is: a string in the 
format "hour h minute" (that's small caps letter "H"), but in which 
"hour h" would also be recognized as a full hour and "00" minutes 
presumed.  The mnemonic is obvious for "hour", which works well for 
English, French, Spanish, Portuguese, not so much for German.

With this, we'd have some example inputs, and their respective results:

8h       -> 08:00
10h30    -> 10:30
18h      -> 18:00
9h-10h   -> 09:00-10:00
9h30-10h -> 09:30-10:00
14h+1h   -> 14:00-15:00

This would ease input in two ways.  First, it presumes the minutes in 
full hours, thus dispensing with this typing.  Considering full hours 
are a very common case for scheduling and appointments, that shortening 
should be significant.  It is also one key shorter than the am/pm way 
for full hours, and two keys shorter for non full hours in the same 
case.  Second, it is easier to type "h" than it is to type ":", it is 
easier to reach and it is not a shift-key, so the chord is gone too.

One corner case which will arise is if "zero hour" should also be 
presumed.  Arguably midnight is not that common in most people's agenda, 
and could be either "0h" or "24h", so we should not really worry in 
shortening something like "midnight and thirty minutes" as "h30".  But 
this is more tricky with duration specification, that is with "+".  In 
this case minutes not comprising a full hour might well be common.  So, 
how to specify an appointment starting at 10:00 that lasts 30 minutes? 
Some alternatives could be: "10h+0h30", "10h+h30", "10h+30m".  On a 
first thought I like the last one better, but I'm really not sure what 
the best approach should be here.

Needless to say, current input conventions should not change.  This is 
just thought as an additional way of inputting time, alongside the ones 
which already exist.  I'm unaware of any use of "h" in the date/time 
prompt (or of "m", for that matter), so I presume this should be viable 
without conflicting with other currently recognized input forms.


That's the small suggestion I had to make for the date/time prompt.  I 
guess, technically, this should be filed as "feature request".  But it 
is just an idea I bring to your consideration, in the hope someone else 
here also likes it.


Best,
Gustavo.

Re: A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

On Thu, May 21 2020, Gustavo Barros wrote:

> format "hour h minute" (that's small caps letter "H"), but 
                                 ^^^^^^^^^^
Sorry, I obviously would like to have said "lowercase" here.

Best,
Gustavo.

Re: A small idea to simplify (further) time input in the date/time prompt

[Eric S Fraga]

On Thursday, 21 May 2020 at 09:29, Gustavo Barros wrote:
> So I'd like to suggest a simplification there, which is: a string in
> the format "hour h minute" (that's small caps letter "H"), but in

I would be strongly in favour of having this option.  This is how I
write times in email messages, for instance, so would be more consistent
for me.  And especially when I communicate with my European partners
when referring to times after 12 noon.

I seem to recollect this coming up before on the list back in the mists
of time, mind you... but I could be mis-recollecting given that we have
no issue tracker. ;-)
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-640-g9bc0cc

Re: A small idea to simplify (further) time input in the date/time prompt

[Robert Horn]

Eric S Fraga writes:

> On Thursday, 21 May 2020 at 09:29, Gustavo Barros wrote:
>> So I'd like to suggest a simplification there, which is: a string in
>> the format "hour h minute" (that's small caps letter "H"), but in
>
> I would be strongly in favour of having this option.  This is how I
> write times in email messages, for instance, so would be more consistent
> for me.  And especially when I communicate with my European partners
> when referring to times after 12 noon.
>

I would be opposed.  There are already dozens of different formats used
in different situations and locations for writing the time.  This would
be yet another different time format.  It is relatively unique in that
there is no other place in the world that uses it.  I don't think that
uniqueness is an argument in its favor.

There some other formats that are actually in widespread use worldwide
that I would prefer as available alternatives:

European dot notation.  Many people use the dot rather than the colon,
so 13:05 is written as 13.05.  I think this is mostly a keyboard, pen, and
pencil thing.  Colon is harder to write.  It's inconveniently located on
many keyboards.  The problem with dot notation is potential confusion
for more detailed time.  "15:53:00.322348" is easy to guess and
understand.  "15.53.00.322348" is more confusing.

Military time, which is used in most militaries, aviation, etc.

  hhmmZ - Time in UTC on a 24-hr clock, also called "Zulu time".  The
  ISO 8601 time "11:21:00 -0400" would be 1521Z.  This is almost
  mandatory when dealing with multi-location scheduling so that everyone
  uses the same time base.
  
  hhmmJ or hhmmh - Time in local zone on a 24-hr clock.  It's widely
  used in military organizations for times that do not need
  multi-location scheduling.  The time "1121J" or "1121h" is usually
  spoken in English as "eleven twenty one hours".  These times are also
  lack the colon typing problem.  

I've not pushed for these mostly because convenience typing military
time isn't worth figuring out all the changes that would be needed.

It's worth looking at all the issues discussed in ISO 8601 and
understanding them before you leap into time formatting changes.  ISO
8601 is a compromise solution with lots of warts, but it is widely
supported and understood.

-- 
Robert Horn
rjhorn@alum.mit.edu

Re: A small idea to simplify (further) time input in the date/time prompt

[Detlef Steuer]

Am Thu, 21 May 2020 11:52:17 -0400
schrieb Robert Horn <rjhorn@panix.com>:

> Eric S Fraga writes:
> 
> > On Thursday, 21 May 2020 at 09:29, Gustavo Barros wrote:  
> >> So I'd like to suggest a simplification there, which is: a string
> >> in the format "hour h minute" (that's small caps letter "H"), but
> >> in  
> >
> > I would be strongly in favour of having this option.  This is how I
> > write times in email messages, for instance, so would be more
> > consistent for me.  And especially when I communicate with my
> > European partners when referring to times after 12 noon.
> >  
> 
> I would be opposed.  There are already dozens of different formats
> used in different situations and locations for writing the time.
> This would be yet another different time format.  It is relatively
> unique in that there is no other place in the world that uses it.  I
> don't think that uniqueness is an argument in its favor.

I find it a natural format living in Europe/Germany.
And I would like the addition, too. It wouldn't take away anything, just
add. But low priority, current ways to specify time work well.

As I understand the propsal it is intended for entering times, not for
storing. Storing and working with times is a different scale of a
problem.

> 
> There some other formats that are actually in widespread use worldwide
> that I would prefer as available alternatives:
> 
> European dot notation.  Many people use the dot rather than the colon,
> so 13:05 is written as 13.05.

And that I`ve never seen (tm). The dots are for dates, colons for time.
May be there is a country with dot notation as a "standard", but definitely
it is not a "European" dot notation.

Regards
Detlef


> I think this is mostly a keyboard,
> pen, and pencil thing.  Colon is harder to write.  It's
> inconveniently located on many keyboards.  The problem with dot
> notation is potential confusion for more detailed time.
> "15:53:00.322348" is easy to guess and understand.  "15.53.00.322348"
> is more confusing.
> 
> Military time, which is used in most militaries, aviation, etc.
> 
>   hhmmZ - Time in UTC on a 24-hr clock, also called "Zulu time".  The
>   ISO 8601 time "11:21:00 -0400" would be 1521Z.  This is almost
>   mandatory when dealing with multi-location scheduling so that
> everyone uses the same time base.
>   
>   hhmmJ or hhmmh - Time in local zone on a 24-hr clock.  It's widely
>   used in military organizations for times that do not need
>   multi-location scheduling.  The time "1121J" or "1121h" is usually
>   spoken in English as "eleven twenty one hours".  These times are
> also lack the colon typing problem.  
> 
> I've not pushed for these mostly because convenience typing military
> time isn't worth figuring out all the changes that would be needed.
> 
> It's worth looking at all the issues discussed in ISO 8601 and
> understanding them before you leap into time formatting changes.  ISO
> 8601 is a compromise solution with lots of warts, but it is widely
> supported and understood.
> 

Re: A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

Hi Robert,

On Thu, May 21 2020, Robert Horn wrote:

> Eric S Fraga writes:
>
>> On Thursday, 21 May 2020 at 09:29, Gustavo Barros wrote:
>>> So I'd like to suggest a simplification there, which is: a string in
>>> the format "hour h minute" (that's small caps letter "H"), but in
>>
>> I would be strongly in favour of having this option.  This is how I
>> write times in email messages, for instance, so would be more 
>> consistent
>> for me.  And especially when I communicate with my European partners
>> when referring to times after 12 noon.
>>
>
> I would be opposed.  There are already dozens of different formats 
> used
> in different situations and locations for writing the time.  This 
> would
> be yet another different time format.  It is relatively unique in that
> there is no other place in the world that uses it.  I don't think that
> uniqueness is an argument in its favor.
>
> There some other formats that are actually in widespread use worldwide
> that I would prefer as available alternatives:
>
> European dot notation.  Many people use the dot rather than the colon,
> so 13:05 is written as 13.05.  I think this is mostly a keyboard, pen, 
> and
> pencil thing.  Colon is harder to write.  It's inconveniently located 
> on
> many keyboards.  The problem with dot notation is potential confusion
> for more detailed time.  "15:53:00.322348" is easy to guess and
> understand.  "15.53.00.322348" is more confusing.
>
> Military time, which is used in most militaries, aviation, etc.
>
>   hhmmZ - Time in UTC on a 24-hr clock, also called "Zulu time".  The
>   ISO 8601 time "11:21:00 -0400" would be 1521Z.  This is almost
>   mandatory when dealing with multi-location scheduling so that 
>   everyone
>   uses the same time base.
>   
>   hhmmJ or hhmmh - Time in local zone on a 24-hr clock.  It's widely
>   used in military organizations for times that do not need
>   multi-location scheduling.  The time "1121J" or "1121h" is usually
>   spoken in English as "eleven twenty one hours".  These times are 
>   also
>   lack the colon typing problem.  
>
> I've not pushed for these mostly because convenience typing military
> time isn't worth figuring out all the changes that would be needed.
>
> It's worth looking at all the issues discussed in ISO 8601 and
> understanding them before you leap into time formatting changes.  ISO
> 8601 is a compromise solution with lots of warts, but it is widely
> supported and understood.

I do appreciate your arguments.  But in reading them, I'd like to 
emphasize that I'm not in any way suggesting the timestamps be changed 
at all.  The suggestion regards exclusively adding and extra way to 
input such times in the date/time prompt.  And one which I feel is very 
much in the spirit of the prompt, which already takes ".", "+4d" (even 
just "+4"), "+2w", "+2tue" as valid date specifications.  If I get this 
spirit correctly, it is to be smart in allowing short and easy input for 
the common cases, and the less common ones are handled by the 
full/formal date/time specification, which can always be inserted 
anyway.  This kind of input simplification is already taken far for 
dates in the date/time prompt, but less so for time.  And that's the 
only point my suggestion tries to address.  I have no particular 
attachment for the "h" input form I suggested, except that it seemed 
natural (Eric's response seems to endorse it).  If other ways to 
simplify input of time come up, they'd be equally appreciated, as far as 
I'm concerned.  And if none come up, the current date/time prompt would 
still be my favorite tool for the task, of course. ;-)

Best,
Gustavo.

Re: A small idea to simplify (further) time input in the date/time prompt

[Robert Horn]

Gustavo Barros writes:

> Hi Robert,
>
> I do appreciate your arguments.  But in reading them, I'd like to
> emphasize that I'm not in any way suggesting the timestamps be changed
> at all.  The suggestion regards exclusively adding and extra way to
> input such times in the date/time prompt.  And one which I feel is

In this context I don't mind, it's the timestamp storage that shouldn't
change.  I lost that detail in the mail trace.  It's something to make
clear and will likely cause confusion among users too.

Detlef,

the dot notation is from DIN 1355 and DIN 5008.  It was changed to use
colons in 1995 to match ISO 8601.  There are still many traditionalists
and old documents.  Look for phrases like "6.30 Uhr" in old documents.
You will find a lot like that.  I didn't like the dot notation and agreed
with the 1995 change, but it's still a reality.

-- 
Robert Horn
rjhorn@alum.mit.edu

Re: A small idea to simplify (further) time input in the date/time prompt

[Bastien]

Hi Gustavo,

I like this idea, thanks for proposing it.  We are in feature freeze
for core features, so we have time to work on this for Org 9.5.

Gustavo Barros <gusbrs.2016@gmail.com> writes:

> With this, we'd have some example inputs, and their respective results:
>
> 8h       -> 08:00
> 10h30    -> 10:30
> 18h      -> 18:00
> 9h-10h   -> 09:00-10:00
> 9h30-10h -> 09:30-10:00

All the above looks good to me as more flexible ways to input time. 

But:

> 14h+1h   -> 14:00-15:00

is not necessary.  Instead, 14h+1 should produce 14:00-15:00.

This way, the "+" in "[hour]+N" as the same meaning, whether [hour] is
formed as HH:MM or as Hh.

Would you agree?  Would you like to work on this change?

Thanks,

-- 
 Bastien

Re: A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

Hi Bastien,

On Tue, Jun 02 2020, Bastien wrote:

> I like this idea, thanks for proposing it.  We are in feature freeze
> for core features, so we have time to work on this for Org 9.5.

Of course, there's absolutely no rush in this, and this is clearly not 
something to be added shortly before a release.  Thank you very much for 
considering it.

> Gustavo Barros <gusbrs.2016@gmail.com> writes:
>
>> With this, we'd have some example inputs, and their respective 
>> results:
>>
>> 8h       -> 08:00
>> 10h30    -> 10:30
>> 18h      -> 18:00
>> 9h-10h   -> 09:00-10:00
>> 9h30-10h -> 09:30-10:00
>
> All the above looks good to me as more flexible ways to input time. 
>
> But:
>
>> 14h+1h   -> 14:00-15:00
>
> is not necessary.  Instead, 14h+1 should produce 14:00-15:00.
>
> This way, the "+" in "[hour]+N" as the same meaning, whether [hour] is
> formed as HH:MM or as Hh.
> 
> Would you agree?

I wasn't aware that a plain number after "+" in "[hour]+N" was 
interpreted as "N hours", I always went for a "3-4 digit plus colon" 
format to specify duration.  But this is indeed a strong argument for 
things to work the same way for both kinds of input.

Besides, I like the idea, but I'm probably missing something.  In this 
case, how would you then input a duration smaller than an hour? Let's 
say 30 minutes? 

> Would you like to work on this change?

I'm not sure I'm up for the task, but I would be willing to try. 
However, there's another problem.  I can't offer signed papers for the 
foreseeable future.  I'd love to, I've contacted FSF to do so last year, 
but my current employment terms imposed a barrier there, which I cannot 
circumvent.  So I've been trying to contribute in the ways that I can, 
with ideas, reports, and so on.  And I hope to be doing so with good 
ones.

Anyway, if you, with your knowledge of the date/time prompt, think this 
sort of change might fit into a "tiny change" (even if it turns out it 
doesn't, ex-post), I'd be willing to give it a shot.  But otherwise, 
I've got my hands tied.

Thanks again.

Best,
Gustavo.

Re: A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

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

Hi Bastien,

On Tue, Jun 02 2020, Bastien wrote:

> Hi Gustavo,
>
> I like this idea, thanks for proposing it.  We are in feature freeze
> for core features, so we have time to work on this for Org 9.5.
>

[...]

> Would you agree?  Would you like to work on this change?

Well, I did give it a shot.  And, as it turns out, this might be 
manageable within my limitations.

A preliminary patch is attached, for comments.

I took here the stance of following the same treatment which is given to 
am/pm times, and of using the letter "h" as sole main identifier.  In 
particular, standard "HH:MM" times take precedence, as is the case for 
am/pm times.  And duration specification with numbers only are presumed 
to be hours, which was already the case, the patch does not introduce 
any changes here.  The input will match for this format for "number h 
2-digit-number", where either the hour or the minutes, but not both, can 
be omitted and, if so, is presumed to be zero.  24h format is also 
presumed.

With it, some example inputs/outputs for time in the date/time prompt:

| input     |      output |
|-----------+-------------|
| 9h        |       09:00 |
| h45       |       00:45 |
| 21h       |       21:00 |
| 9h-10h    | 09:00-10:00 |
| 9h--10h30 | 09:00-10:30 |
| 18h30+h30 | 18:30-19:00 |
| 18h30+1   | 18:30-19:30 |
| 18h30+1h  | 18:30-19:30 |

And some sanity checks:

| input     | output               | Observation 
  |
|-----------+----------------------+-------------------------------------------|
| 10:00 9h  | 10:00                | by design, as for am/pm times 
  |
| 10am 9h   | 10:00                | expected from coming after am/pm 
  handling |
| 10:00-11h | 10:00-11:00          | 
  |
| 10h-11:00 | no match             | am/pm also does not match here 
  |
| +9h       | no match             | 
  |
| -9h       | no match             | 
   |
| h         | no match             | 
  |
| 10h+h     | no match             | 
  |
| h5        | no match             | 
  |
| 10h70     | no match             | 
  |
| 29h       | 2020-06-04 Thu 05:00 | makes sense, same as for 29:00 
  |
| 30h       | no match             | as per the regexp 
  |

WDYT?

Best,
Gustavo.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-date-time-prompt-Provide-support-for-HHhMM-time-inpu.patch --]
[-- Type: text/x-diff, Size: 2075 bytes --]

From 02829c7771a1f7a0c00d607a924fb8f56d2f3dd6 Mon Sep 17 00:00:00 2001
From: Gustavo Barros <gusbrs.2016@gmail.com>
Date: Wed, 3 Jun 2020 08:57:53 -0300
Subject: [PATCH] date/time prompt: Provide support for HHhMM time input

* lisp/org.el (org-read-date-analyze): Add support for HHhMM time
input, in similar way as for am/pm times.
* doc/org-manual.org (The date/time prompt): Add example to illustrate
the feature.

TINYCHANGE
---
 doc/org-manual.org |  1 +
 lisp/org.el        | 13 +++++++++++++
 2 files changed, 14 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index 92252179b..bfd2aea1f 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -6017,6 +6017,7 @@ dash(es) as the separator in the former case and use =+= as the
 separator in the latter case, e.g.:
 
 | =11am-1:15pm=  | \rArr{} 11:00-13:15   |
+| =11h-13h15=    | \rArr{} same as above |
 | =11am--1:15pm= | \rArr{} same as above |
 | =11am+2:15=    | \rArr{} same as above |
 
diff --git a/lisp/org.el b/lisp/org.el
index b869e12e1..8333e1a5a 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -13981,6 +13981,19 @@ user."
 	       (setq ans (replace-match (format "%02d:%02d" hour minute)
 					t t ans))))
 
+    ;; Help matching HHhMM times, similarly as for am/pm times.
+    (cl-loop for i from 1 to 2 do	; twice, for end time as well
+	     (when (and (not (string-match "\\(\\`\\|[^+]\\)[012]?[0-9]:[0-9][0-9]\\([ \t\n]\\|$\\)" ans))
+			(string-match "\\(?:\\(?1:[012]?[0-9]\\)?h\\(?2:[0-5][0-9]\\)\\)\\|\\(?:\\(?1:[012]?[0-9]\\)h\\(?2:[0-5][0-9]\\)?\\)\\>" ans))
+	       (setq hour (if (match-end 1)
+				(string-to-number (match-string 1 ans))
+			      0)
+		     minute (if (match-end 2)
+				(string-to-number (match-string 2 ans))
+			      0))
+	       (setq ans (replace-match (format "%02d:%02d" hour minute)
+					t t ans))))
+
     ;; Check if a time range is given as a duration
     (when (string-match "\\([012]?[0-9]\\):\\([0-6][0-9]\\)\\+\\([012]?[0-9]\\)\\(:\\([0-5][0-9]\\)\\)?" ans)
       (setq hour (string-to-number (match-string 1 ans))
-- 
2.17.1

Re: A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

Hi All,
Hi Bastien,

if I may kindly bump this patch for review.

Best regards,
Gustavo.

On Wed, 03 Jun 2020 at 10:14, Gustavo Barros <gusbrs.2016@gmail.com> 
wrote:

> Hi Bastien,
>
> On Tue, Jun 02 2020, Bastien wrote:
>
>> Hi Gustavo,
>>
>> I like this idea, thanks for proposing it.  We are in feature freeze
>> for core features, so we have time to work on this for Org 9.5.
>>
>
> [...]
>
>> Would you agree?  Would you like to work on this change?
>
> Well, I did give it a shot.  And, as it turns out, this might be 
> manageable within my limitations.
>
> A preliminary patch is attached, for comments.
>
> I took here the stance of following the same treatment which is given 
> to 
> am/pm times, and of using the letter "h" as sole main identifier.  In 
> particular, standard "HH:MM" times take precedence, as is the case for 
> am/pm times.  And duration specification with numbers only are 
> presumed 
> to be hours, which was already the case, the patch does not introduce 
> any changes here.  The input will match for this format for "number h 
> 2-digit-number", where either the hour or the minutes, but not both, 
> can 
> be omitted and, if so, is presumed to be zero.  24h format is also 
> presumed.
>
> With it, some example inputs/outputs for time in the date/time prompt:
>
> | input     |      output |
> |-----------+-------------|
> | 9h        |       09:00 |
> | h45       |       00:45 |
> | 21h       |       21:00 |
> | 9h-10h    | 09:00-10:00 |
> | 9h--10h30 | 09:00-10:30 |
> | 18h30+h30 | 18:30-19:00 |
> | 18h30+1   | 18:30-19:30 |
> | 18h30+1h  | 18:30-19:30 |
>
> And some sanity checks:
>
> | input     | output               | Observation 
>   |
> |-----------+----------------------+-------------------------------------------|
> | 10:00 9h  | 10:00                | by design, as for am/pm times 
>   |
> | 10am 9h   | 10:00                | expected from coming after am/pm 
>   handling |
> | 10:00-11h | 10:00-11:00          | 
>   |
> | 10h-11:00 | no match             | am/pm also does not match here 
>   |
> | +9h       | no match             | 
>   |
> | -9h       | no match             | 
>    |
> | h         | no match             | 
>   |
> | 10h+h     | no match             | 
>   |
> | h5        | no match             | 
>   |
> | 10h70     | no match             | 
>   |
> | 29h       | 2020-06-04 Thu 05:00 | makes sense, same as for 29:00 
>   |
> | 30h       | no match             | as per the regexp 
>   |
>
> WDYT?
>
> Best,
> Gustavo.

Re: A small idea to simplify (further) time input in the date/time prompt

[Bastien]

Hi Gustavo,

sorry for the slow reply.

I applied this patch in master with commit e8562a332.

Thanks!

-- 
 Bastien

Re: A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

Hi Bastien,

On Sat, 01 May 2021 at 12:40, Bastien <bzg@gnu.org> wrote:

> Hi Gustavo,
>
> sorry for the slow reply.
>
> I applied this patch in master with commit e8562a332.
>
> Thanks!

Thank you very much!
Looking forward to enjoy this one.

Best,
Gustavo.

Re: A small idea to simplify (further) time input in the date/time prompt

[stardiviner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Gustavo Barros <gusbrs.2016@gmail.com> writes:

> Hi All,
>
> the Org date/time prompt does deliver the promise in the manual that we "start
> getting annoyed by pretty
> much any other way of entering a date/time out there".  It has indeed become so
> for me, as the date/time prompt is very neat.  But there is one place where
> input could be even shorter, which is time input.
>
> Currently, time input mostly requires "hour colon minutes", thus a full time
> specification even when minutes are "00".  And "mostly" because you can get away
> with that last part if you use am/pm convention (alas, I do not belong to those
> strange corners of the world).  Besides, the colon is a shift-key in many common
> keyboard layouts (from a simple search, it seems to be so in British, American,
> US International, German, Spanish, and Portuguese layouts, it doesn't seem to be
> so for the French layout though).
>
> So I'd like to suggest a simplification there, which is: a string in the format
> "hour h minute" (that's small caps letter "H"), but in which "hour h" would also
> be recognized as a full hour and "00" minutes presumed.  The mnemonic is obvious
> for "hour", which works well for English, French, Spanish, Portuguese, not so
> much for German.
>
> With this, we'd have some example inputs, and their respective results:
>
> 8h       -> 08:00
> 10h30    -> 10:30
> 18h      -> 18:00
> 9h-10h   -> 09:00-10:00
> 9h30-10h -> 09:30-10:00
> 14h+1h   -> 14:00-15:00
>

Which date/time prompt do you mean? Like set schedule or deadline? If just raw
timestamp, it makes me confused whether it is time continuance.

> This would ease input in two ways.  First, it presumes the minutes in full
> hours, thus dispensing with this typing.  Considering full hours are a very
> common case for scheduling and appointments, that shortening should be
> significant.  It is also one key shorter than the am/pm way for full hours, and
> two keys shorter for non full hours in the same case.  Second, it is easier to
> type "h" than it is to type ":", it is easier to reach and it is not a
> shift-key, so the chord is gone too.
>
> One corner case which will arise is if "zero hour" should also be presumed.
> Arguably midnight is not that common in most people's agenda, and could be
> either "0h" or "24h", so we should not really worry in shortening something like
> "midnight and thirty minutes" as "h30".  But this is more tricky with duration
> specification, that is with "+".  In this case minutes not comprising a full
> hour might well be common.  So, how to specify an appointment starting at 10:00
> that lasts 30 minutes? Some alternatives could be: "10h+0h30", "10h+h30",
> "10h+30m".  On a first thought I like the last one better, but I'm really not
> sure what the best approach should be here.
>
> Needless to say, current input conventions should not change.  This is just
> thought as an additional way of inputting time, alongside the ones which already
> exist.  I'm unaware of any use of "h" in the date/time prompt (or of "m", for
> that matter), so I presume this should be viable without conflicting with other
> currently recognized input forms.
>
>
> That's the small suggestion I had to make for the date/time prompt.  I guess,
> technically, this should be filed as "feature request".  But it is just an idea
> I bring to your consideration, in the hope someone else here also likes it.
>
>
> Best,
> Gustavo.


- -- 
[ stardiviner ]
       I try to make every word tell the meaning that I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-----BEGIN PGP SIGNATURE-----

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7WWxwUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsOi4Qf/RpkotaYxjmrDA+SsjqK4ep7sLM+Y
tLwm+N47cYYDGPNR3M9o9WZYNxLncygdxXF2eYQjX7DQHmuZ8rLLyNa3Yb9P7vUb
OYywOyTWgSa5wgp1cOJepcFS384DZvZeSg+odhrJDr5wPfhfN7NpbhB3VB3TLiEr
hIHx1XzBfZbNifMR90gupPIZt2IEfHqcoI7zGa1uHfoDRPYDU61m2cVj4ZZDc1Ya
H8gPAFQD+oGbg32PUw6vQn4a6x7Qk668G0kP52e5yCISG8S5P7BKrk0HSKClPUxM
GjH0kYVm5DzEOm6YQvnWfGr2EIDuHLlMxvBaxyIXmMYc+k61RBAisKS1WA==
=QSbI
-----END PGP SIGNATURE-----

Re: A small idea to simplify (further) time input in the date/time prompt

[Gustavo Barros]

Hi stardiviner,

On Tue, Jun 02 2020, stardiviner wrote:
>
> Which date/time prompt do you mean? Like set schedule or deadline? If 
> just raw
> timestamp, it makes me confused whether it is time continuance.
>

The date/time prompt is Org's interface for querying for date and time 
which is described in the [[info:org#The date/time prompt]] section of 
the manual.  It is indeed the interface you get when calling 
'org-time-stamp', 'org-schedule', 'org-deadline' etc.

As mentioned before in the thread, the suggestion is orthogonal to the 
timestamp format or with document syntax.  It is just an alternative way 
to input time in the date/time prompt, which should produce the same 
good old timestamp.

Best,
Gustavo.

Re: A small idea to simplify (further) time input in the date/time prompt

[stardiviner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


Gustavo Barros <gusbrs.2016@gmail.com> writes:

> Hi stardiviner,
>
> On Tue, Jun 02 2020, stardiviner wrote:
>>
>> Which date/time prompt do you mean? Like set schedule or deadline? If just raw
>> timestamp, it makes me confused whether it is time continuance.
>>
>
> The date/time prompt is Org's interface for querying for date and time which is
> described in the [[info:org#The date/time prompt]] section of the manual.  It is
> indeed the interface you get when calling 'org-time-stamp', 'org-schedule',
> 'org-deadline' etc.

Thanks for declaration. I see, I have not noticed Org have this way treating
input time value. Glad about learning new stuff.

> As mentioned before in the thread, the suggestion is orthogonal to the timestamp
> format or with document syntax.  It is just an alternative way to input time in
> the date/time prompt, which should produce the same good old timestamp.

That's great.

>
> Best,
> Gustavo.


- -- 
[ stardiviner ]
       I try to make every word tell the meaning that I want to express.

       Blog: https://stardiviner.github.io/
       IRC(freenode): stardiviner, Matrix: stardiviner
       GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
-----BEGIN PGP SIGNATURE-----

iQFIBAEBCAAyFiEE8J9lDX1nSBmJJZFAG13xyVromsMFAl7WZXMUHG51bWJjaGls
ZEBnbWFpbC5jb20ACgkQG13xyVromsOcUgf/X765J3pj9TdAXLKy+IWNH9KTB92y
H0KR25vOZmKqxnrSDrjxajbiJ/iSQkujaVJMsfAGf4v/w+GSeqtHqip745BIhGIb
2TG6dOpE1L3FnKREmC93uuSs3bemciezD4CM7qAjB1DvpNVGiy4NiEbzmoHPjMpY
arvxObEeHmceOEc/1oqFlJfmb7sO5YKfd4xoAHofr+sSpVrG7ophbIAHNVQiAhvt
gQItQ7wudD9wlp42dBP6V56W2ON2VXIuDpCWNEpjvx3MtxvGgvoa1Y8x+RqB3pd6
TL60qk85wdwLRcjl69q2P9Zz4XBk3iWOHfL9mIBJ7ZKqtHwBVzy/6olTig==
=VaY4
-----END PGP SIGNATURE-----