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.