bear / parsedatetime

Parse human-readable date/time strings
Apache License 2.0
695 stars 106 forks source link

tm_yday calculated incorrectly when exact date given #232

Open youve opened 5 years ago

youve commented 5 years ago

First thanks for making parsedatetime. It's really great.

These are correct:

>>> import parsedatetime as pdt
>>> cal = pdt.Calendar()
>>> cal.parse('today')
(time.struct_time(tm_year=2018, tm_mon=11, tm_mday=24, tm_hour=9, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=328, tm_isdst=-1), 1)
>>> cal.parse('next saturday')
(time.struct_time(tm_year=2018, tm_mon=12, tm_mday=1, tm_hour=9, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=335, tm_isdst=-1), 1)```

This is wrong:

>>> cal.parse('December 1st')
(time.struct_time(tm_year=2018, tm_mon=12, tm_mday=1, tm_hour=19, tm_min=44, tm_sec=55, tm_wday=5, tm_yday=328, tm_isdst=0), 1)

As you can see, today is the 328th day of the year, and next Saturday is the 335th day of the year. But if I tell it to parse "December 1st" then suddenly next Saturday has the same tm_yday as today.

I think this bug is with parsedatetime and not upstream because time gets it right:

>>> time.strptime('01 December 2018', '%d %B %Y')
time.struct_time(tm_year=2018, tm_mon=12, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=5, tm_yday=335, tm_isdst=-1)
youve commented 5 years ago

I think it happens because when there's a relative date, a timedelta is added to now, so the timedelta fills in tm_yday for us. When there's an exact date, tm_yday just isn't filled in at all so it's defaulting to today's tm_yday.

youve commented 5 years ago

yeah. see:

>>> cal.parse('3rd december')
(time.struct_time(tm_year=2018, tm_mon=12, tm_mday=3, tm_hour=23, tm_min=19, tm_sec=58, tm_wday=0, tm_yday=330, tm_isdst=0), 1)
>>> cal.parse('today plus 3rd december')
2018-11-26 23:20:02,681 - DEBUG - eval plus with context - True, False
(time.struct_time(tm_year=2018, tm_mon=12, tm_mday=3, tm_hour=9, tm_min=0, tm_sec=0, tm_wday=0, tm_yday=337, tm_isdst=-1), 1)