andrew-morris / parsedatetime

Automatically exported from code.google.com/p/parsedatetime
0 stars 0 forks source link

Dates in the past #37

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
In my particular use case, I am entering dates that are in the near past. 
parsedatetime works really great except that it assumes I'm typing future 
dates. That is, when it guess the year, it guesses the next possible year.

For example, I type in Jan 5th which has just happened. I mean Jan 5th, 2011. 
However, parsedatetime picks Jan 5th, 2012.

I did try passing a date exactly one year into the past as the source time 
parameter. But this did not seem to work.

Here is a small script to reproduce what I tried:

from parsedatetime import parsedatetime

calendar = parsedatetime.Calendar()

baseline = (1999, 0, 0, 0, 0, 0, 0)

result = calendar.parse('Jan 5', baseline)
print result

I expected to get Jan 5, 1900 but instead I got:

((2012, 1, 5, 21, 19, 50, 2, 12, 0), 1)

Original issue reported on code.google.com by WinstonEwert on 13 Jan 2011 at 3:21

GoogleCodeExporter commented 8 years ago
Have you looked into using the YearParseStyle constant?  
parsedatetime.Calendar() will create a parsedatetime.Constants() object if you 
don't pass one in, but if you do then you can override a lot about how it 
handles those items.

The best docs are in the source for parsedatetime.Constants as each item has a 
lot of comment text describing how it changes the way the parsing is handled.

Original comment by bear42 on 13 Jan 2011 at 8:11

GoogleCodeExporter commented 8 years ago
I can't find any references to YearParseStyle either in my copy or in the repo. 

Original comment by WinstonEwert on 13 Jan 2011 at 8:40

GoogleCodeExporter commented 8 years ago
oh wow - FAIL on my part - it's a local change I haven't posted yet.

I've attached a patch that implements it

Original comment by bear42 on 13 Jan 2011 at 10:50

Attachments:

GoogleCodeExporter commented 8 years ago
So that patch makes it take the current year as the year. That certainly 
handles most cases. The ideal situation would be if it would pick the closest 
date either forwards or backwards.

I've solved my immediate problem by eliminating the skip forward logic in my 
local copy. 

Original comment by WinstonEwert on 14 Jan 2011 at 12:05

GoogleCodeExporter commented 8 years ago
hmm, then I must have read your description incorrectly.  I'm planning on 
giving the project some much needed bug and code love this weekend, so I will 
look at implementing that behaviour as an option.

thanks!

Original comment by bear42 on 14 Jan 2011 at 4:19

GoogleCodeExporter commented 8 years ago
I didn't describe what I'd ideally want. My actual concern was more that my 
start date's year seemed to be ignored.

Original comment by WinstonEwert on 15 Jan 2011 at 12:23