ScheduleRuleIsDstAdjusted Property

Gets or sets a value indicating whether the daylight savings time adjustments should be applied.

Namespace:  Dundas.BI.Scheduling
Assembly:  Dundas.BI.Core (in Dundas.BI.Core.dll) Version: 2.0.0.0 (24.4.0.1000)
Syntax
public bool IsDstAdjusted { get; set; }

Property Value

Type: Boolean
The value of if the DST adjustments should be applied; otherwise, .
Remarks

It set to , the calculation of the Next Run Time will be adjusted according to the daylight savings time (DST) rules associated with the specified TimeZoneId. If set to , the calculation is made in Coordinated Universal Time (UTC) and not adjusted to any time zone DST.

Set it to if you want to keep constant interval between your scheduled jobs. Set it to if you want to have the scheduled job run at exact local time(s).

For example, consider the following scenario: you created a rule "At 4:00 PM every day, starting 2016-01-01", so some notification email will be sent to you at this time; your web server is in Eastern Time.

If you set it to , the 4:00 PM would be saved and calculated as 9:00 PM UTC every day, and the notification email comes at 4:00 PM. Once the DST starts on 2016-03-13, the notification email will start coming at 5:00 PM Eastern Time, because the UTC offset has changed from 5 to 4 hours.

If you set to and specify the time zone as "Eastern Time", the 4:00 PM would be saved and calculated as a UTC time that always converted to 4:00 PM, no matter if DST is in effect or not.

Note that if you set it to , and the calculated next run time produces an invalid local time (see IsInvalidTime(DateTime)), it would be adjusted according to the time zone DST rules. For example, next run time calculated as 2016-03-13 2:00 AM local time would become 2016-03-13 3:00 AM local time.

Similarly, if you set it to , and calculation of next run time produces an ambiguous local time (see IsAmbiguousTime(DateTime)), it would be calculated as after DST ends. For example, next run time calculated as 2016-11-06 1:00 AM Eastern Time would be translated to 2016-11-06 6:00 AM UTC, which maps back to 2016-11-06 1:00 AM ET after DST ends (and not to 2016-11-06 5:00 AM UTC, which could have mapped back to 2016-11-06 1:00 AM ET during the DST).

See Also