Parsedatetime

Updated setup.py for wheel compatibility
renamed README.txt to README.rst
renamed MANIFEST to MANIFEST.in
cleaned up a lot of the doc and notes

Commit 3fc165e701 mafagafo Now it works for Python 3.4.1
Commit d5883801e7 borgstrom Restore Python 2.6 compatibility

8 Jul 2014 - bear
bumped version to 1.4

Issue 45 make a new release to really fix backwards compatibility
Issue 43 Please tag version 1.3

Commit 29c5c8961d devainandor fixed Python 3 compatibility in pdtLocale_icu
Commit d7304f18f7 inean Fix support for 'now' when no modifiers are present
Commit 26bfc91c28 sashaacker Added parseDT method.
Commit 848deb47e2 rmecham Added support for dotted meridians.
Commit c821e08ce2 ccho-sevenrooms corrected misspelling of 'thirteen'

24 Jan 2014 - bear
bumped version to 1.3

many changes - amazing how hard it is to keep this file up to date
when using GitHub.

See https://github.com/bear/parsedatetime/commits/master for details.

Biggest change is the addition of the nlp() function by Geoffrey Floyd:
nlp() function that utilizes parse() after making judgements about
what datetime information belongs together. It makes logical groupings
based on proximity and returns a parsed datetime for each matched
grouping of datetime text, along with location info within the given inputString.

27 Jun 2013 - bear
bumped version to 1.2

04 Mar 2013 - bear
bumped version to 1.1.2

deploy import fix from Antonio Messina
also noticed that the urls were pointing to my older site, corrected

03 Mar 2013 - bear
bumped version to 1.1.1

Ugh - debug log caused an error during formatting
Issue 10 https://github.com/bear/parsedatetime/issues/10

14 Nov 2012 - bear

Added test for "last friday"
Updated MANIFEST to reflect renamed README file
Bumped version to 1.1

15 Mar 2011 - bear

Updated 1.0.0 code to work with 2.6+ (need to try 2.5) and also updated
docs and other supporting code

07 Sep 2009 - bear

Created branches/python25 from current trunk to save the current code

Converted trunk to Python 3 and also refactored how the module is structured
so that it no longer requires import parsedatetime.parsedatetime

Bumped version to 1.0.0 to reflect the major refactoring

07 Jan 2009 - bear

Apply patch submitted by Michael Lim to fix the problem parsedatetime
was having handling dates when the month day preceeded the month
Issue 26 http://code.google.com/p/parsedatetime/issues/detail?id=26

Fixed TestErrors when in a local where the bad date actually returns
a date ;)

Checked in the TestGermanLocale unit test file missed from previous commit

20 Apr 2008 - bear

Upating Copyright year info
Fixing defects from Google Project page

The comparison routine for the "failing" test was not accurate.
The test was being flagged as failing incorrectly
Issue 18 http://code.google.com/p/parsedatetime/issues/detail?id=18

Added patch from Bernd Zeimetz for the German localized constants!
http://svn.debian.org/viewsvn/*checkout*/python-modules/packages/parsedatetime/trunk/debian/patches/locale-de.dpatch
He identifies some issues with how unicode is handled and also some other
glitches - will have to work on them
Issue 20 http://code.google.com/p/parsedatetime/issues/detail?id=20

Tweaked run_tests.py to default to all tests if not given on the command line
Removed 'this' from the list of "specials" - it was causing some grief and from the
looks of the unit tests, not all that necessary

Worked on bug 19 - Bernd identified that for the German locale the dayofweek check
was being triggered for the dayoffset word "morgen" (the "mo" matched the day "morgen")
To solve this I added a small check to make sure if the whole word being checked was
not in the dayOffsets list, and if so not trigger.
Issue 19 http://code.google.com/p/parsedatetime/issues/detail?id=19


28 Nov 2007 - bear

bumping version to 0.8.6 in trunk

Fixing two bugs found by Chandler QA

Time range of "today 3:30-5pm" was actually causing a traceback.
Added a new regex to cover this range type and a new test.

OSAF 11299 https://bugzilla.osafoundation.org/show_bug.cgi?id=11299

A really embarrassing for a date/time library - was actually *not*
considering leap years when returning days in a month!
Added tests for Feb 29th of various known leap years and also added
a check for the daysInMonth() routine which was created to replace
the naively simple DaysInMonthList.

OSAF 11203 https://bugzilla.osafoundation.org/show_bug.cgi?id=11203

12 Jun 2007 - bear

bumping version to 0.8.5 in trunk


22 Feb 2007 - bear

Fixed a bug reported via the code.google project page by Alexis where
parsedatetime was not parsing day suffixes properly. For example, the
text "Aug 25th, 2008" would return the year as 2007 - the parser was
not 'seeing' 2008 as a part of the expression.

The fix was to enhance one of the "long date" regexes to handle that
situation but yet not break the current tests - always fun for sure!

Issue 16 http://code.google.com/p/parsedatetime/issues/detail?id=16


21 Feb 2007 - bear

Fixed a bug Brian K. (one of the Chandler devs) found when parsing with
the locale set to fr_FR. The phrase "same 3 folders" was causing a key
error inside the parser and it turns out that it's because short weekday
names in French have a trailing '.' so "sam." was being used in the
regular expression and the '.' was being treated as a regex symbol and
not as a period.

It turned out to be a simple fix - just needed to add some code to run
re.escape over the lists before adding them to the re_values dictionary.

Also added a TestFrenchLocale set of unit tests but made them only run
if PyICU is found until I can build an internal locale for fr_FR.
Issue 17 http://code.google.com/p/parsedatetime/issues/detail?id=17


14 Feb 2007 - bear

Minor doc string changes and other typo fixes

Updated Copyright years

Added a fallbackLocales=[] parameter to parsedatetime_consts init routine
to control what locales are scanned if the default or given locale is not
found in PyICU.
Issue 9 http://code.google.com/p/parsedatetime/issues/detail?id=9

While working on the regex compile-on-demand issue below, I realized that
parsedatetime was storing the compiled regex's locally and that this would
cause prevent parsedatetime from switching locales easily. I've always
wanted to make it so parsedatetime can be set to parse within a locale just
by changing a single reference - this is one step closer to that.

Made the regex compiles on-demand to help with performance
Requested by the Chandler folks
Issue 15 http://code.google.com/p/parsedatetime/issues/detail?id=15

To test the change I ran 100 times the following code:
for i in range(0, 100):
c = pdc.Constants()
p = pdt.Calendar(c)
p = None
c = None

and that was measured by hotshot:

24356 function calls (22630 primitive calls) in 0.188 CPU seconds

after the change:

5000 function calls in 0.140 CPU seconds

but that doesn't test the true time as it doesn't reference any regex's
so any time saved is deferred. To test this I then ran before and after
tests where I parsed the major unit test bits:

before the change:

80290 function calls (75929 primitive calls) in 1.055 CPU seconds

after the change:

55803 function calls (52445 primitive calls) in 0.997 CPU seconds

This tells me while doing the lazy compile does save time, it's not a lot
over the normal usage. I'll leave it in as it is saving time for the
simple use-cases.


27 Dec 2006 - bear

Added some support files to try and increase our cheesecake index :)

Created an examples directory and added back the docs/* content so the
source distribution will contain the generated docs

Changed how setup.py works to allow for a doc command

26 Dec 2006 - bear