apply PREFER_DAY_OF_MONTH in date.py

[noviluni]

fixes #607

[codecov]

Codecov Report

Merging #611 into master will increase coverage by 0.08%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master    #611      +/-   ##
=========================================
+ Coverage   95.12%   95.2%   +0.08%     
=========================================
  Files         302     302              
  Lines        2503    2505       +2     
=========================================
+ Hits         2381    2385       +4     
+ Misses        122     120       -2

Impacted Files	Coverage Δ
dateparser/parser.py	98.88% <100%> (+0.53%)	⬆️
dateparser/utils/__init__.py	96.8% <100%> (+0.27%)	⬆️
dateparser/date.py	97.94% <100%> (-0.03%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f4b493f...421ae78. Read the comment docs.

[noviluni]

(Explanation and example in a comment in the linked issue)

[Gallaecio]

What I found most strange about #607 was that, depending on whether the date format input parameter was a list (['%m/%Y']) or a string ('%m/%Y'), the output date was different.

I think that is something we need to address and cover in the tests before we can consider #607 solved.

[noviluni]

@Gallaecio
I think there was a confusion.

Currently, doing this:

>>> dateparser.parse('02/2013', ['%m/%Y'])                                                                                                                                                                  
datetime.datetime(2013, 2, 28, 0, 0)

Is the same than doing this:

>>> dateparser.parse('02/2013', '%m/%Y')                                                                                                                                                                    
/home/marc/workprojects/dateparser/dateparser/date.py:142: FutureWarning: Date formats should be list, tuple or set of strings
  warn(_DateLocaleParser.DATE_FORMATS_ERROR_MESSAGE, FutureWarning)
datetime.datetime(2013, 2, 28, 0, 0)

(except for the deprecation warning). In the example in the issue, the second statement is

datetime.strptime('02/2013', '%m/%Y')

which is using the datetime.strptime, not the dateparse.parse method.

[Gallaecio]

🤦‍♂️

[Gallaecio]

💄 What about apply_day_of_the_month_from_settings, to be consistent with apply_timezone_from_settings?

[noviluni]

Hmmm... This was my first approach, but then I didn't like that naming. First of all "apply" seems to mean that you are "adding" something. It maybe has sense for the timezone, as sometimes you add it, but I'm not sure if this has sense for the day as what you are doing is to change it.

Secondly, apply_day_of_the_month_from_settings seems to mean that it is getting the day from the settings; but what it is doing is using the rules in the settings to find the correct day.

For both reasons I prefer this naming: set_correct_day_from_settings.

What do you think @Gallaecio ? Any better idea?

[noviluni]

Note to self: I could also add a unit test for the function get_last_day_of_month (including all months and at least one example of leap year).