2

We have a program that inserts a weekly scheduled task for performing a local backup.

The event is generated using class WeeklyTrigger and inserted in windows task scheduler. The bulk code of registration is:

var wt = new WeeklyTrigger
{
    DaysOfWeek = weekday,
    StartBoundary = startDate,
    Enabled = true
};
using (TaskService ts = new TaskService())
{
    TaskDefinition td = ts.NewTask();
    td.RegistrationInfo.Description = "Backup";
    td.Triggers.Add(wt);
    td.Actions.Add(Application.ExecutablePath, arg);
    td.Settings.ExecutionTimeLimit = TimeSpan.Zero;
    ts.RootFolder.RegisterTaskDefinition(name, td);
}

This works correclty but inserts the scheduled task with option Syncronize across time zones enabled which sets scheduled time as UTC. With this configuration when Daylight saving time starts (or ends) the task running time is not updated and this results in 1 hour offset from the expected running time.

Disabling Syncronize across time zones option let the scheduled task to run using local time.

enter image description here

Edit, to be more clear If we schedule the task for monday at 10:00 CET with daylight saving time and then when daylight saving time is removed the set time stays in UTC and the task is then started on monday at 09:00 CET. We want to avoid this because users plans their backup at the end of their work week and an hour before or after can make a huge difference in data integrity.

Is it possibile to create the scheduled task without the Syncronize across time zones options programmatically? Is there some specific documentation that we can check?

Zucch
  • 297
  • 1
  • 6
  • 15
  • Just use local time. The time should always be stored as UTC and then the machine should automatically make adjustments for timezone without you having to do in code. – jdweng Oct 30 '20 at 17:04
  • @jdweng I have used local time but the scheduled event is weekly and when the daylight saving time start the saved time doesn't change with it. I'll update the question to be more clear. – Zucch Oct 30 '20 at 17:09
  • Why would the local time change? As I said the operating system compensated automatically. UTC time doesn't change. So when you program a time it gets store in UTC. Then when the timezone changes your offset changes and your local time changes which cancels the the time in the GUI is correct. – jdweng Oct 30 '20 at 17:13
  • @jdweng very unclear what you mean... 9am local time is sometime 01:00Z and sometime 02:00Z... how do you suggest to store those two values in a single datetime field as UTC? (even more entertaining cases covered by the Jon Skeet's https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/) – Alexei Levenkov Oct 30 '20 at 18:29
  • @AlexeiLevenkov : The operating system does the conversion automatically. When you enter local time the date is stored in UTF using the machines timezone. And likewise retrieving data is done using the machines timezone. Take a time and store the time. Then change the machine timezone. The time will change. – jdweng Oct 30 '20 at 20:43
  • @jdweng "The time will change." - yes, that is the exact problem described in the post - if you set your alarm with UTC time you'll wake up 8am in winter and 9am in summer... Which is not what most people consider "9am". – Alexei Levenkov Oct 30 '20 at 21:17
  • @AlexeiLevenkov : The OP said in the response above is didn't change. – jdweng Oct 31 '20 at 09:18

1 Answers1

1

The solution is to directly modify the XML text which defines the task. This can be get/set using the TaskDefinition.XmlText property.

Find more information on what exactly you need to modify here.

230Daniel
  • 432
  • 3
  • 16