A missing “+” for a whitespace match between month name and year is causing the year to not parse when an extra space is provided. E.g:

>>> parsedatetime.Calendar().parse("August 2016")
(time.struct_time(tm_year=2016, tm_mon=8, tm_mday=1, tm_hour=16, tm_min=41, tm_sec=35, tm_wday=1, tm_yday=236, tm_isdst=1), 1)
>>> parsedatetime.Calendar().parse("August  2016")
(time.struct_time(tm_year=2017, tm_mon=8, tm_mday=1, tm_hour=20, tm_min=16, tm_sec=0, tm_wday=1, tm_yday=236, tm_isdst=1), 3)

This PR adds the missing “+” and a test for the scenario.

This change is

When it is February 29 (like today!), parsedatetime.Calendar().parse("1 year") raises

ValueError: day is out of range for month

(It's trying to find February 29 in the following non-leap year, i.e., February 29, 2017.)

I think this is unexpected behavior because people would expect to be able to specify relative time intervals in terms of years on any day. (For example, we had written code that always computes parse("1 year") relative to the present day, and it crashes when run today!)

$ python3 run_tests.py parsedatetime
..................F..............................
======================================================================
FAIL: testMonths (parsedatetime.tests.TestUnits.test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./parsedatetime/tests/TestUnits.py", line 107, in testMonths
    self.assertTrue(_compareResults(self.cal.parse('1 month',  start), (target, 1)))
AssertionError: False is not true

----------------------------------------------------------------------
Ran 49 tests in 0.284s

FAILED (failures=1)

I do this:

cal = parsedatetime.Calendar() datetime_obj, parse_status = cal.parseDT(datetimeString='thursday 6:00 am', tzinfo=timezone('Europe/Bucharest'))

Resulting time I get is this:

2016-06-30 03:00:00+00:00

Here's the problem: I get this result when I run the query at 6:40am on June 30th.

I think what's happening is because it's pre 9am (or some other time), it returns a time that has already passed instead of the following Thursday. eg. I was expecting this: 2016-07-07 03:00:00+00:00

I don't see this in the docs, but will do more testing. Any input appreciated on why this happens. I'm expecting to say "Thursday 6:00am" and if the current time in given timezone is past 6am, return the following Thursday. I'm not seeing this behavior, though.

Thank you -

This is a refactor of current parsedatetime module. I removed all *Flag attributes from Calendar object and used thread-safe pdtContext to replace them. There are two huge methods in Calendar class, the parse() and _evalString(). They have been broke up into several small methods.

Also, this pull request introduced a new system to record if certain datetime string contains year, month, week, day, hour, minute, second, halfday (for example, afternoon or midnight) or "now". With such ability, not only we can know if the string contains date/time, but also the accuracy of date/time it brings with.

Method parse() and parseDT() are both added a new parameter "version". When version equals to 1 which is also the current default value, the methods' second return value is still the old "flag" style 0, 1, 2 or 3. But if version equals to 2, the methods will return a pdtContext object, which allows user to inspect the text deeper.

Fixes a scenario where there's a time before a modifier:

>>> parsedatetime.Calendar().parse("1pm next Friday")
(time.struct_time(tm_year=2016, tm_mon=9, tm_mday=2, tm_hour=4, tm_min=14, tm_sec=58, tm_wday=4, tm_yday=246, tm_isdst=-1), 3)

This addresses the immediate issue by differentiating between the modifiers a little more - "next Friday" is not the same as "after Friday". There might be a deeper issue here of assuming that the first chunk is an offset (like "1 hour") when in fact, it could be a fully qualified time ("1 pm").

This change is

Error: "Unresolved attribute reference 'parse' for class 'object'... " in Pycharm IDE.

Version: parsedatetime-1.5

Code to reproduce:

    from time import mktime
    import parsedatetime
    from datetime import datetime

    cal = parsedatetime.Calendar()
    time_struct, parse_status = cal.parse("tomorrow")
    datetime.fromtimestamp(mktime(time_struct))

cal.parse -> cal is not being detects as class Calendar and instead as object, which of course has no definition parse. Not sure what exactly is causing this, but my guess would be due to Calendar() being embedded in the init.py file.

I do not see this issue while importing any other python modules.

I get random occurrences of the following error:

AttributeError: 'thread._local' object has no attribute 'stack'

I'm using the library in the process of an HTTP request and I think that might be interfering with the use of thread locals.

For example, neither "$300" nor "300ml" are intended to be "3:00" but "300" and "300am" are fine. The time must be preceded by a space or hyphen (the hyphen is to allow 300-400 style ranges) or appear at the beginning of the string. The time (or time + meridian for AM/PM locales) must be followed by a word boundary.

I opted for (\s|-|^) here since, especially considering currencies, many different symbols can precede a number and most will be treated as a word boundary. \b would not have fixed the $300 case.

This is another one where I'm not sure if all cases are covered but the tests pass and it seems in general to be an improvement.

I did not make any changes to evalRanges via RE_RTIMEHMS and RE_RTIMEHMS2 which look like they may still have word boundary issues. Both (\s?|^) (which due to the ? can match anything) and the lack of \b are a bit concerning. For completion since this version is somewhat focused on word boundary fixes we should probably fix those as well.

Otherwise, I think this wraps up my work for this version. Will post a few ideas for the future but I'm not quite ready to get into some of the other parsedatetime-related issues that have come up in my project.

Hi, is it possible to recursively look for all dates in a text, for example extract one, eliminate this chunk of text, parse again for the next one, and so on? Any tips on how I should go for this using parsedatetime?

Fixes #87 for which I had previously employed a workaround in my application to pre-process transform next month to in 1 month. I am submitting this as a pull request in the hope of some feedback or additional test cases. nlp() is somewhat under-tested; while I was able to find and fix a few resulting issues there are probably more cases to test. I would like to have a few eyes on this before I merge it in.

Adjacency of modifier and unit

It would not be acceptable to pull out standalone units as dates; simply mentioning the word "week" does not imply a specific date. Instead I required that these units be immediately preceded by a modifier, such that next week parses as a date but neither A week is a long time nor Next I will rest for a week parse as dates.

Handling of number + unit pairs was not consistent

One detail of the orginal nlp implementation stuck out to me. In the code that processes matches, there is a comment about proximity of terms and making logical combinations of phrases. Inside the loop, only phrases representing a date or time are parsed (excluding the third type, units). Only on the last iteration were units considered (if date or time or units: outside the loop vs if date or time: inside the loop).

I added units within the loop, which could be a source of regression errors if there was a specific reason for that decision. I noticed that the test for nlp was passing only because the number + unit phrase in 5 minutes coincidentally appeared as the last matched phrase in the test. Move that sentence (And in 5 minutes I'm going to eat some food!) to the beginning of the test string and the test fails.

@geoffreyfloyd, it was a few years ago but do you happen to remember if there was a reason the units were only checked outside the loop in 9401d0d1b6b400710af66fc9dc01d137288cdb3a?

Postfix modifiers?

In some locales such as Spanish the modifier follows the unit. For example, the English phrase next month could be any of the following in Spanish: el próximo mes, el mes que viene, el mes siguiente. I am unsure whether parsedatetime supports such postfix modifiers in parse(), but this commit will not support that format.

Bumps certifi from 2021.10.8 to 2022.12.7.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

This change is 

testNextMonth fails on February 29th - it returns a date two years later instead of one (e.g. 2022-02-28 instead of 2021-02-28 with a base date of 2020-02-29).

This test reproduces the issue:

def testNextMonthLeapYear(self):
    s = datetime.datetime(2020, 2, 29, self.hr, self.mn, self.sec)
    t = self.cal.inc(s, year=1)
    start = s.timetuple()
    target = t.timetuple()

    self.assertEqual(_tr(self.cal.parse('next February 28', start)),
                     _tr((target, pdtContext(pdtContext.ACU_MONTH | pdtContext.ACU_DAY))))

Output

AssertionError: Tuples differ: ((2022, 2, 28, 8, 21, 0, 0, 0, 0), pdtContext([47 chars]DAY)) != ((2021, 2, 28, 8, 21, 0, 0, 0, 0), pdtContext([47 chars]DAY))

First differing element 0:
(2022, 2, 28, 8, 21, 0, 0, 0, 0)
(2021, 2, 28, 8, 21, 0, 0, 0, 0)

- ((2022, 2, 28, 8, 21, 0, 0, 0, 0),
?        ---

+ ((2021, 2, 28, 8, 21, 0, 0, 0, 0),
?      +++

   pdtContext(accuracy=pdtContext.ACU_MONTH | pdtContext.ACU_DAY))

Initially reported by @hroncok in https://bugzilla.redhat.com/show_bug.cgi?id=1808449

this might seem weird, but I think those two should be different:

>>> import parsedatetime; "{}".format(parsedatetime.Calendar().parseDT("next tuesday 18:00", tzinfo=pytz.timezone("CET"))[0])
'2022-03-29 18:00:00+02:00'
>>> import parsedatetime; "{}".format(parsedatetime.Calendar().parseDT("next tuesday 18:00 UTC", tzinfo=pytz.timezone("CET"))[0])
'2022-03-29 18:00:00+02:00'
>>> 

ie. if I specifically pass a timezone in my date string, shouldn't parsedetime at least try to parse that timestamp?

this also fails with more regular date formats:

>>> import parsedatetime; "{}".format(parsedatetime.Calendar().parseDT("2022-03-03 18:00 UTC", tzinfo=pytz.timezone("CET"))[0])
'2022-03-03 18:00:00+01:00'
>>> import parsedatetime; "{}".format(parsedatetime.Calendar().parseDT("2022-03-03 18:00 UTC", tzinfo=pytz.timezone("EST"))[0])
'2022-03-03 18:00:00-05:00'
>>> 

Hello,

there is currently no support for preceding 'previous' modifiers used in some slavic languages, but afaik also German and Spanish... To explain what I mean: In Czech, to say eg 4 hours ago, we say před 4 hodinami, in German they say vor 4 Stunden etc. - the modifier precedes the time.

Is there a simple way to implement a change like this at the moment? Thank you!

It seems that parse("yesterday at 5") does not interpret 5 as time (i.e. hours). It would be nice if this was the case, as this seems a natural way of expressing time of day. From a brief look at the code, it looks like 5 on its own is too general to be interpreted as an indication of hours, however, I think that at could be used to pinpoint the meaning of the integer number.

I understand that in locales that do not use the 24h clock, the simple 5 might be ambiguous (see #210), but at the moment this also does not work in locales that use the 24h clock. For example in the de_DE locale, gestern um 5 and gestern um 17 do not get parsed correctly and the default time of the locale is used.