💡 [FEAT] make the dateparser return date in the furture as default

[arvyanh]

Is your feature request related to a problem? 😢 Please describe.
when enter "1d" in the date, the the updated date is 1 day back in time

Describe the solution you'd like 🤔
I think in 99% cases when we are editing a todo's date, we are trying to write a date in future (instead of a date back in time)
so I suggest in utils/dateparser file, change the line to:

    #(add the prefer_dates_from settings)
    return dateparse(value, settings={"DATE_ORDER": DATE_ORDER, 'PREFER_DATES_FROM': 'future'})

The effect:

[ins] In [1]: from dateparser import parse

[ins] In [2]: parse('1d', settings={'PREFER_DATES_FROM': 'future'})
Out[2]: datetime.datetime(2023, 8, 2, 1, 53, 51, 960598)

[ins] In [3]: parse('1d')
Out[3]: datetime.datetime(2023, 7, 31, 1, 54, 2, 871494)

[kraanzu]

Hey @arvyanh,
Thanks for opening the issue. I'm actually thinking of removing dateparser because it slows down the startup time of the app which can be significant depending on your machine :(
and nobody will want to use a todo app that opens slowly see this

Instead I'm using dateutil which has less features but is very fast and does not affect load times. If you know a workaround or any other library feel free to share :)

[arvyanh]

Just had a brief look at the dateutil, which the .parser doesn't seems to support the "1d" I've mentioned earlier. (n d or n day seems results in the nth day of the month)

Maybe try parsedatetime, which seems to be a lot faster during import (on my machine) and supports both the "1d" I said and the absolute date? (Personally, I think these kinds of short hand would be pretty important/useful for todo apps)

(it's pip installed vs pacman installed, so I can't say if there's issue with this simple testing)

echo "import parsedatetime\ncal=parsedatetime.Calendar()" | time python   --> 0:00.03
echo "import dateparser" | time python  --> 0:00.18

[ins] In [52]: cal = parsedatetime.Calendar()

[ins] In [53]: cal.parse("1d")
Out[53]: 
(time.struct_time(tm_year=2023, tm_mon=8, tm_mday=2, tm_hour=3, tm_min=26, tm_sec=11, tm_wday=2, tm_yday=214, tm_isdst=-1),
 1)

[ins] In [54]: cal.parse("8-1")
Out[54]: 
(time.struct_time(tm_year=2023, tm_mon=8, tm_mday=1, tm_hour=3, tm_min=26, tm_sec=16, tm_wday=1, tm_yday=213, tm_isdst=0),
 1)

[kraanzu]

Hmm..just tried comparing the three of them, same results as you, and not much difference for parsedatetime and dateutil !
Thanks a lot for the suggestion :)

[kraanzu]

This is pretty good except it'd implicitly also set the time too!
For eg "8 mar" is processed as "8 march HH:MM" where HH:MM is the current time
A workaround can detect whether the user wants to include time or not

is_time_included = any(i in value.lower() for i in [":", "@", "at", "am", "pm"])

something like this. How'd you mention time explicitly?