NextRunTime returning 30/12/1899 00:00:00

Apr 4, 2012 at 8:54 AM


I've succesfully used this (fantastic) library to schedule a task which correctly fired off last night as expected and all seemed well. However I've now noticed that the NextRunTime returned by the library is "30/12/1899 00:00:00", whereas the value shown in Task Scheduler is "11/04/2012 04:30:00".  I've included a code snippet below which pulls back the task incase I'm doing something wrong in there, although all the other task properties seem to be correct at this stage.


Task task = ts.GetTask("usertask-" + Environment.ExpandEnvironmentVariables("%username%"));

if (task != null)
 LastRunTime = task.LastRunTime;
 LastTaskResult = task.LastTaskResult;
 NextRunTime = task.NextRunTime;
 State = task.State.ToString();


The problem only occurs after the schedule has run - i.e. when the task is first created the DateTime is read back correctly, but after Windows has run the task and updated the task, an incorrect value is returned.

Any help or pointers would be much appreciated - I'm coding in C# using Visual Studio 2010, targetting .Net 4.0 on Windows 7 x64 and I've downloaded the 1.8.1 release of the library.

Thanks for your time,


Apr 4, 2012 at 4:49 PM

If NextRunTime == new DateTime(1899, 12, 30) then there is no future time at which the task is scheduled to run. What trigger are you setting for the task?

Apr 5, 2012 at 7:01 AM


Thanks for your reply.

It's a weekly trigger, and the normal Windows Task Scheduler UI correctly displays the next run time as "11/04/2012 04:30:00" (I'm in the UK so, DateTime(2012, 04, 11, 04, 30, 00)).


Apr 5, 2012 at 9:37 PM

I have heard of this problem before on remote servers. That value is pulled directly from the COM object so I really have no way of correcting it in my library. One workaround has been the following:

DateTime[] nrts = task.GetRunTimes(DateTime.Now, DateTime.Now.AddYears(100), 1);
DateTime nrt = nrts.Length > 0 ? nrts[0] : DateTime.MinValue;
Apr 10, 2012 at 7:06 AM

Ok, no problem - thanks for taking the time to look at it.

Thanks for the suggested workaround too :-)