It's OK - it took a while for me to understand it too - hence the blog article. I had to write it all out to understand it and see what it did.

I think the mistake is thinking that the PartitionNumber column is actually the number of days old that the row actually is. It isn't that at all - it's the result of the calculation with the modulo of 3. Data written today (01 Apr 2015) will have a value of 2 - it isn't an indication of the age of the row, just which partition it wants to store it in.

Tomorrow's data will want to be in PartitionNumber 3 - try it:

SELECT abs(datediff(day,CONVERT([date],'20000101',(112)),'20150401')%(3)+(1))

SELECT abs(datediff(day,CONVERT([date],'20000101',(112)),'20150402')%(3)+(1))

So the purging process uses the same calculation, works out that PartitionNumber 3 is required tomorrow and so switches the data out of partition 3 and truncates it, leaving it empty for the following day.

Because there are three partitions it cycles through them each day, always clearing the one that it needs to use the next day (if the job is scheduled correctly).

If you wanted a monthly partition scheme then for each month the calculation would calculate a partition number for the row created at that time (based on 'month' instead of 'day'). It wouldn't actually be the age (in months) of that partition, just the result of the calculation. As long as it is consistent for the month and the purge process uses the same calculation then it will have a monthly partition and purging system.