[Forum FAQ] Fixing scheduled task Next Run Time displaying as expired time plus days to delete

Question

Symptom:
We used Task Scheduler to create a scheduled task. For example, we configured a daily task, starting from 3 AM 9/3/2014, recurring the task every 1 day, and set the expiration time as 3 AM 9/3/2015 (See Figure 1). Under
Settings tab, we checked If the task is not scheduled to run again, delete if after:
option, and set the value as 30 days (See Figure 2).
However, in the Task Scheduler Library snap-in, we saw that the Next Run Time of the task is 3AM 10/3/2015, which equals expiration date plus days to delete (See Figure 3), but the right value should be 3 AM 9/2/2014 because the task has never been run.
Figure 1
Figure 2
Figure 3
Cause:
This is a Task Scheduler interface displaying issue. Although the next run time that is displayed in the Task Schedule is incorrect, the trigger will be fired correctly.
Solution:
We can install the hotfix in the following KB article to fix the displaying issue, though the symptom in the article is different.
An incorrect value for Next Run Time is displayed when you specify multiple triggers to schedule a task in Windows Vista, Windows 7, Windows Server 2008 or Windows Server 2008 R2
http://support.microsoft.com/kb/2495489
After installing the hotfix, we need to restart computers to make it take effect.
In this example, after installing the hotfix and restarting the computer, we see that the next run time of the task is displayed correctly in Task Scheduler (Figure 4).
Figure 4

Answer 1

I am not running out of space, but I do have the same problem.  Every so often TM does a backup which is about 60 GB bigger than expected.   The  extra is always a new backup of /System /Applications /usr etc. - that is the 'system files'.
The key thing is, as you have noticed:
Examining the content of the latest backup, the one that did not fail, shows that some system directories, /Applications, /usr, and /bin are missing
As a consequence the next backup is, in my case, 60 GB bigger because it includes all the system files.
It is as if 'systemFilesExcluded' was turned on for the previous backup (the one that 'did not fail').  But I have looked in the .exclusions.plist for this backup and it is exactly the same as for other backups and does include:
        <key>systemFilesExcluded</key>
        <false/>
It seems that TM is treating this as if <true/>.
Like you, I have done a disk verify and it finds no errors.
I think this must be a bug.  I have had this on four occassions since upgrading to Mountain Lion.  And it is doing a large one right now - I have caught it in the act!