scrapinghub / scrapinghub/dateparser
search.search_dates - having hard time with "am" and "next" (with examples)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 2.9k
- Forks
- 520
- Avg merge
- 22h 56m
- Merged PRs (30d)
- 6
Description
Hi all,
I've noticed that when I use "am" in search_dates it doesn't work, but when supplied with :minutes it works fine (below is the output of installation and usage with some comments). "pm" seems to work ok.
Also having issue when searching for example "next monday" - it returns past monday.
Maybe it's just me, any advise is appreciated.
# installing dateparser
(venv) ~/Py/myproject pip install dateparser
Collecting dateparser
Using cached dateparser-1.1.0-py2.py3-none-any.whl (288 kB)
Collecting pytz
Using cached pytz-2021.3-py2.py3-none-any.whl (503 kB)
Collecting python-dateutil
Using cached python_dateutil-2.8.2-py2.py3-none-any.whl (247 kB)
Collecting regex!=2019.02.19,!=2021.8.27
Using cached regex-2022.1.18-cp39-cp39-macosx_10_9_x86_64.whl (288 kB)
Collecting tzlocal
Using cached tzlocal-4.1-py3-none-any.whl (19 kB)
Collecting six>=1.5
Using cached six-1.16.0-py2.py3-none-any.whl (11 kB)
Collecting pytz-deprecation-shim
Using cached pytz_deprecation_shim-0.1.0.post0-py2.py3-none-any.whl (15 kB)
Collecting tzdata
Using cached tzdata-2021.5-py2.py3-none-any.whl (339 kB)
Installing collected packages: tzdata, six, pytz-deprecation-shim, tzlocal, regex, pytz, python-dateutil, dateparser
Successfully installed dateparser-1.1.0 python-dateutil-2.8.2 pytz-2021.3 pytz-deprecation-shim-0.1.0.post0 regex-2022.1.18 six-1.16.0 tzdata-2021.5 tzlocal-4.1
(venv) ~/Py/myproject python3
Python 3.9.8 (main, Nov 10 2021, 09:21:22)
[Clang 13.0.0 (clang-1300.0.29.3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from dateparser import search
# - first check am vs pm
>>> search.search_dates("in 3 days at 1pm")
[('in 3 days at 1pm', datetime.datetime(2022, 1, 23, 13, 0))]
>>> search.search_dates("in 3 days at 1am")
[('in 3 days at 1am', datetime.datetime(2022, 1, 23, 16, 44, 27, 62654))]
# - second check 2am vs 2pm vs 2:00am
>>> search.search_dates("tomorrow 2pm")
[('tomorrow 2pm', datetime.datetime(2022, 1, 21, 14, 0))]
>>> search.search_dates("tomorrow 2am")
[('tomorrow 2am', datetime.datetime(2022, 1, 21, 16, 45, 9, 662876))]
>>> search.search_dates("tomorrow 2:00am")
[('tomorrow 2:00am', datetime.datetime(2022, 1, 21, 2, 0))]
# - issue with next (using today for reference)
>>> search.search_dates("today")
[('today', datetime.datetime(2022, 1, 20, 16, 56, 22, 87891))]
>>> search.search_dates("next monday")
[('monday', datetime.datetime(2022, 1, 17, 0, 0))]
Thank you for this amazing module 🙏 it's such a timesaver and sorry if I missed similar issue from earlier.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the reported cases through the search.search_dates entry point, especially the examples using “1am”, “2am”, and “next monday”. Trace how these expressions are interpreted and add coverage for the reported behavior; done means AM times and the next weekday resolve to the expected dates and times.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100