Comment 2 for bug 1190112

Copied from merge proposal:

Adds a monthsend interval_type and special handling which it requires.

This change also fixes existing subtle bug that could affect monthly crons. In explaining it, hopefully it will help clarify why the new method works the way it does.

The issue is easiest to see by example:

Take user who has timezone Pacific/Auckland (NZST +12 or NZDT +13)
If they set up a monthly job to run from the 31st of May, they will then see the next run scheduled for 1st July (NZST) instead of 30th June.

To show how that happens -
UI (NZST) -> DB (UTC) -> add month DB (UTC) -> UI (NZST)
31/05 10am -> 30/05 10pm -> 30/06 10pm -> 01/07 10am

Since this issue also affects monthsend calculations the fix adds a new method to perform date calculation in the timezone of the user running the job (if they have one set). So the flow is instead:

UI (NZST) -> DB (UTC) -> Local -> add month Local -> DB (UTC) -> UI (NZST)
31/05 10am -> 30/05 10pm -> 31/05 10am -> 30/06 10am -> 29/06 10pm -> 30/06 10am

With this fix, the additional monthsend interval type is handled as a special case of month interval type. It localizes the datetime as above but then has to move that to be the first of the month so that date calculation is thereby a simple add extra month and subtract a day.

A followup change to openobject-addons/subscription/subscription.py will be required for change to be used by users setting up recurring events. It is only:
- 'interval_type': fields.selection([('days', 'Days'), ('weeks', 'Weeks'), ('months', 'Months')], 'Interval Unit'),
+ 'interval_type': fields.selection([('days', 'Days'), ('weeks', 'Weeks'), ('months', 'Months'), ('monthsend', 'End of Months')], 'Interval Unit'),