The Daylight Saving field indicates whether Daylight Saving Time (Summer Time) applies in the locale where the entity is situated. When Daylight Saving time is applicable, the value will usually be 1. Value will be 0 when Daylight Saving Time is not observed (for example, most of the province of Saskatchewan in Canada, the states of Arizona and Hawaii and the commonwealth of Puerto Rico in the United States). The offset will be 2 in cases where a locale observes "double daylight saving time" (for example, for several years in the 1990s, the Canadian province of Newfoundland moved clocks ahead by two hours for the summer months).
If the clocks will be moving forward or backward while a load is moving, the schedule for stops that occur after the switch will account for the "missing" or "extra" hour.
Scheduling does not handle cases where there are different Daylight Saving Time rules applicable for different shipping locations in the same TM instance (for example, locations in North America, Europe, Australia). Dates for Daylight Saving Time observance will be based on the time zone of the server. Therefore, if server is located in North America but all planning is for locations in Europe, the server's time zone should be set to one of the European time zones.
Also, scheduling does not formally handle regions like Arizona, USA and most of Saskatchewan, Canada that do not observe Daylight Saving Time. Without intervention, schedules between locations that observe Daylight Saving Time and those that do not will be off by an hour during the period of Daylight Saving Time observance in surrounding areas. To handle regions like Arizona and Saskatchewan, updates must be performed (manually or by script) in the spring and fall to adjust the Time Zone Offset for locations in areas that do not observe Daylight Saving Time so that the Time Zone Offset accurately reflects the current relative difference between locations in that area and the base time zone. If Daylight Saving Time Zones have been configured properly, locations where Daylight Saving Time Offset is zero will be in regions that do not observe Daylight Saving Time; for these locations, add 1 hour to the Time Zone Offset in the spring and subtract 1 hour in the fall.
Dates/times cannot be entered for the hour that is "skipped" when daylight saving time begins to be observed. This is based on the time zone of the application. When a user enters a date/time that falls within the "invalid" hour, the date/time supplied by the user will be overridden with the first "legal" data/time that follows the "invalid" interval.