Extend the query date parser with (optional) times

[discopatrick]

I had a brief chat with @sampsyo about this on the beets irc channel. I just wanted to formally register myself as beginning this job here.

We can currently query based on date:

beet ls 'added:2008-12-01..2008-12-02'

The plan is to additionally allow querying on time:

beet ls 'added:2008-12-01 12:30:55..2008-12-02 19:15:22'

Without having looked at the code yet, I'm wondering whether the following are going to be problematic:
a) the space between date and time,
b) the colon symbols within the time.

If anyone can confirm this off the top of their head, and can advise on an approach, please do. Maybe it will work just fine. Maybe we'll need to change 2008-12-01 12:30:55 to 2008-12-01-12-30-55.

Beets can also do shorthand date queries, like:

beet ls 'added:2008-12..2009-10-11'

I would also like to be able to do shorthand time queries, like this:

beet ls 'added:2008-12-01 12:..2008-12-02 19:15:'

i.e. list items added on or after 2008-12-01 12:00:00, but before 2008-12-02 19:16:00

I'll shout if I get stuck!

[discopatrick]

Development on this feature is now underway: discopatrick@ba324df

So far, it has seemed fairly logical to me that date queries including times should use the 'T' separator format, e.g.: added:2000-01-01T12:30..2000-01-01T12:31

However, I can't decide whether using the 'T' separator makes the query more readable or less readable than if we just used a space:

With minute precision:
'added:2000-01-01 12:30..2000-01-01 12:31' vs added:2000-01-01T12:30..2000-01-01T12:31

With hour precision:
'added:2000-01-01 12..2000-01-01 13' vs added:2000-01-01T12..2000-01-01T13

The 'T' separator makes it quite clear that what follows is a time value. This is most apparent when using hour precision - it's not immediately clear what the lone 12 and 13 stand for in the example using spaces. The 'T' also has the added benefit of keeping the value as one string of characters with no whitespace, and means you don't have to quote the query.

On the other hand, using a space separator keeps the format consistent with that which beet list outputs:

patrick$ ./beet list added:2017-04-13T11:43..2017-04-13T11:43
2017-04-13 11:43:08 - Danny Byrd - Supersized - Shock Out
2017-04-13 11:43:08 - Danny Byrd - Supersized - Weird Science
...

Thus, using the space separator in queries would allow someone to pipe the output of beet list into other beets commands that accept queries as parameters. (Would that ever be useful?)

patrick$ ./beet list -f '$added'
2017-04-13 11:57:14
...

If we wanted to keep our options open, we could have a config option that lets us choose beets' datetime output format:

--- # config.yaml
datetime_output_format: %Y-%m-%dT%H:%M:%s

Initial testing shows that both formats pass all the existing tests (on Python 2 at least).

Any advice or strong opinions on which way to go?

[sampsyo]

Neat! One easy way would be to just allow either one. The parser could just match either a "t" (case insensitively) or whitespace. That would allow queries that are easy to type in the console as the same time as more legible queries in other contexts—in the situations you've already listed and, for example, in a hypothetical graphical interface where whitespace isn't used to separate query terms.

That's the strategy we use for query negation too: you can use either -foo or ^foo, one of which is less ambiguous and the other of which is easier to type at the command line.