Use more convenient dates and times

[bcudini]

I'd like to have a way to add new events more conveniently. For exemple: khal new thursday drink beer khal new '2 months' laundry

In fact, using GNU date from command line, you can use all kind of dates format, like the ones I explained. I was thinking about using the same in khal, and I would do that myself but don't know where the dates and times are parsed in khal's code. Any pointer would be appreciated, so that I can do it and offer a patch

Thanks

[geier]

This is a good idea and I've thought about this myself.

The problem with using GNU date is, that while it my be legal to import GPL licensed code I'm not sure its not against the wishes of the author. So I would prefer a MIT/BSD etc. licensed package to be used. An apache licensed module for which could be helpful is parsedatetime.

For the where, have a look at construct_event() in khal/aux.py.

If you have any more questions, don't hesitate to ask. I'd love to see a pull request for this.

[untitaker]

I'd consider using GNU tools a valid option re legal situation, but doing so might harm portability.

[untitaker]

You might also want to do this the way GNOME California does: Just take a description, and extract the dt from there if found. We should also add CLI options for enforcing the date with strict behavior (for scripts invoking khal new), and make the user use that if we fail to extract a date.

[geier]

California's quick add looks pretty nice, lots of good ideas waiting to be stolen

[bcudini]

The parsedatetime module looks good, california seems even better but their code is unusable here (looks like it's written in Vala and GPL licenced).

For the where, did you mean construct_event() in khal/aux.py, the function just after generate_random_uid()? I'm looking into it right now and will try to have a working PoC asap

[geier]

@bcudini yes, I did mean construct event(), I don't know how that error happened (corrected it now)

[geier]

I just had a look at california's details parser. While it is obviously a lot better than what we currently have, their approach is at least similar: Tokenize the input string and then use different parsers for different components (start, end, duration, location etc) on that stack, popping elements if they are 'used'.

[geier]

If you want to help with this issue, just write down all variants you can think of a clever quick add function should understand.

[WhyNotHugo]

AFAIK, California's implementation was rather broken in that it expected US-formated date (eg: "Monday 6pm") and did not work with standard time formats ("Monday 1800hs", "Monday 1800", etc), as well as some other really common variations.. However, the high level idea should work.

If you want to help with this issue, just write down all variants you can think of a clever quick add function should understand.

Possible formats for input:

• Beer with Alice tomorrow 1400
• Lunch with bob in two days midday
• Breakfast with Alice Friday quarter to twelve
• Party next Wednesday at midnight
• Beer with Peter on March 2nd
• Meeting in two hours until midnight
• Party tonight at 2000 (note that tonight equals today)
• Beer with Alice in one week

Recurring events sound a bit trickier, but are basically determined by the way every <X> [other] <Y>, X being an integer, and Y can be month, day, week, etc. There's also:

• Beer with Alice every other day starting tomorrow
• Beer with Bob every week
• Beer with Charlie every 2 months.

Non-infinite recurring events:

• Lunch with Mum every Thrusday until June 1st
• Call Mum every day until the end of the year
• Beer with Alice every day from 20 to 22 until next Saturday

Ironically, I don't drink as much beer as you'd expect, they were just the quickest examples. 😄

[geier]

To anyone who wants to start working on this, I would recommend having a look at spacy (which has just been relicensed under MIT license), to me it looks like the most practical solution for natural language processing (I only did some quick experiments with it though).

[geier]

another interesting looking library (haven't tried it yet): https://github.com/akoumjian/datefinder

[WhyNotHugo]

spacy looks great, but not really suited to our needs, regrettably:

__init__: Load the linguistic analysis pipeline. Loading may take up to a minute, and the instance consumes 2 to 3 gigabytes of memory.

[ref]

[geier]

@hobarrera alright, that doesn't look like it fits our use case.

[untitaker]

parsedatetime works very well in todoman for me.