Does anyone know what's happening when I run {{#time:d M Y|2017 + 13 months}} and get 09 May 2025? It doesn't read 2017 as a year and adds 13 months to the current date.
Topic on Help talk:Extension:ParserFunctions/2020-2024
Months are 30.436875 days on average (in the Gregorian calendar, whose years are 365.2425 days on average), but their actual length on calendars is variable and adding months would depend on the starting month and possibly the day, and sometimes on the year if it's in February on leap years (notably when starting on the last few days of months). But calendar months within a year (counted from 1 March to the next year) are aligned as if their length was 30.6 days on average, before rounding the number of days, so distinct calendar months are variable in duration.
When you specify 2017 alone, there's no way to add an exact number of months and get a date with a precision to the day. The function takes the missing month and day from the current date (9 April 2024), and then adds the relevant number of months. The specification "2017" is ignored.
That function could use 1 January of 2017 at 00:00:00) as the base (independantly of the current year) and then add 13 months: 12 months to increase the year from 2017 to 2018, then 1 month to shift from 1 January to 1 February, resulting in 1 February 2018 (at 00:00:00, but you did not tell the function to show the exact time).
When you add a number months it is more simply converted to a number of years, by just dividing this number by 12. The function would then add 1 year and 1 month, but at which day of the month? Some rounding must occur. Other interpretations are possible.
But generally it's not a good idea to add months to any date without specifying an exact date with a precision at least to the day (independantly of the display format "d M Y", which plays no role here).
In NO case you can expect a resulting date in 2017.
Thanks for the reply! I'm working on a template where neither the precision of the date nor the units of time in the addition are known in advance. To get around this issue, I had to implement a workaround converting the date to the more precise DMY format (which borrows the current day/month when not specified) before putting it through w:Template:After, which uses unix time. If you know of a better solution, feel free to lmk or tweak the template yourself!