About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A server's time zone is usually set during build and rarely revisited. On a hosted server it can quietly be different from what the business expects: set to UTC by the provider's template, set to Sydney time when the business is in Brisbane, or set to local time on one server and UTC on another. The difference may go unnoticed until daylight saving starts or ends, and a nightly job runs twice, or not at all, or a report shows transactions in the wrong day.
This article explains how Windows and SQL Server use the time zone, where daylight saving causes trouble, and how to choose a setting deliberately.
Why it matters
Business applications use time for things that matter: invoice dates, payroll cut-offs, interest calculations, audit trails and scheduled imports. A one-hour error in the wrong place can move a transaction into the next day or month.
Australia makes this more likely than many countries. The NSW Government notes that New South Wales, Victoria, South Australia, Tasmania, and the Australian Capital Territory observe daylight saving. Queensland, Western Australia, and the Northern Territory do not. A business with staff in Brisbane and a server set to Sydney time has a one-hour difference for half the year and none for the other half.
How it works
Windows holds the time zone rules
Windows keeps a list of time zones and their daylight saving rules, and applications rely on it. Microsoft explains that Many applications and cloud services reference the underlying Windows operating system for DST and TZ information. When governments change their rules, Microsoft publishes updates through Windows Update (WU).
So a server that misses updates can also have out-of-date time zone rules. Microsoft asks governments for long notice of changes, and when there is not enough time, it says it will publish interim guidance on the DST Blog that can be used up until a Windows Update is made available.
SQL Server takes its time from Windows
SQL Server does not keep its own clock or time zone. Microsoft's documentation for GETDATE says the value is derived from the operating system of the computer on which the instance of SQL Server is running. If the server is set to UTC, GETDATE returns UTC. If it is set to Sydney time, it returns Sydney time, with daylight saving.
SQL Server also offers functions that return UTC directly, and one that returns the local time with its offset from UTC. Microsoft notes that SYSDATETIMEOFFSET includes the system time zone offset. Which one an application uses is decided by its developer, not by the server administrator.
SQL Server's time zone conversions also use the Windows rules: SQL Server relies on time zones that are stored in the Windows Registry.
What happens at the change
Daylight saving creates two awkward hours each year. Using the NSW dates published for 2026–27:
- Start: on Sunday 4 October 2026, at 2am Eastern Standard Time, clocks moved forward to 3am. Local times from 2:00 to 2:59 did not exist that night.
- End: on Sunday 4 April 2027, at 3am Eastern Daylight Time, clocks will move back to 2am. Local times from 2:00 to 2:59 will happen twice.
Microsoft's SQL Server documentation describes the same effect: when clocks go forward, there's a gap in local time equal to the duration of the clock adjustment. When they go back, 2 hours of local time are overlapped onto one hour. It also notes the adjustment is usually 1 hour, but it can be 30 or 45 minutes, depending on time zone.
A job scheduled at 2:30am local time on such a server is exactly in the danger zone. Depending on the scheduler, it may be skipped in October and run twice in April, or run at a shifted time. A job that runs every hour may run 23 or 25 times on the change days. Check how your scheduler behaves; do not assume.
Stored times without an offset are ambiguous
If an application stores local times without any indication of the offset, a record stamped 2:30am on 4 April 2027 could mean either of two moments an hour apart. Microsoft's .NET guidance describes the alternative: a date and time stored with its offset from UTC always unambiguously identifies a single point in time. The SQL Server equivalent is the datetimeoffset type. Note that it stores the offset, not the time zone rules; Microsoft's data type table lists it as not daylight saving aware.
What to choose and why
Option 1: set servers to the business's local time
This is common for small businesses with one location. It means times in the application, logs and reports match what staff see on their own clocks.
The cost is daylight saving: scheduled jobs and stored local times need care around the two change nights each year, if the chosen time zone observes daylight saving.
Option 2: set servers to UTC
UTC has no daylight saving, so a daily job scheduled on a UTC server clock does not meet a missing or repeated hour, and times stored in UTC are not ambiguous. Some providers and organisations standardise on it.
The cost is translation: every time shown to staff must be converted to local time, either by the application or by people reading logs. An application that assumes the server is in local time will show the wrong times.
Option 3: a time zone without daylight saving
A Brisbane-based business can set servers to Brisbane time and avoid daylight saving entirely, while still seeing local time. For a business spread across states, this does not remove the difference between offices; it only removes changes on the server.
Whatever you choose, be consistent and deliberate
- Ask the application vendor. Some applications require a particular setting, or store times in local time and expect it never to change. Changing the time zone of a server under a running application can shift historical data or duplicate scheduled runs.
- Match related servers. An application server and its database server in different time zones can produce off-by-an-hour errors.
- Keep critical jobs out of the change window. On a server that observes daylight saving, avoid scheduling important jobs between 2am and 3am local time.
- Record the decision. Write down each server's time zone and why. A migration is one moment when it can change by accident.
When migrating to a hosted server
Check the time zone of the old server and set the new one to match before restoring data and enabling scheduled jobs, unless you have deliberately decided to change it. A provider template may default to a time zone you did not choose.
Risks and limits
- Changing a server's time zone is not harmless. Applications that stored local times may show past records at the wrong time. Plan and test the change with the vendor.
- Scheduler behaviour differs. Windows Task Scheduler, SQL Server Agent and application schedulers each handle the change hour in their own way. Test on an isolated copy with synthetic data, not on production: set its clock and time zone to cross a change, then check each job's run history and output for skipped or repeated runs.
- Time zone rules come with Windows updates. A server that is not patched may not know about a rule change.
- The dates here are for New South Wales, as published by the NSW Government. Other states and countries differ.
- No commands are given. The time zone is set in Windows settings; changes should be planned, not made on a live system without preparation.
Sources
Opened 14 November 2026.
- NSW Government: Daylight saving in NSW: When it starts and ends in 2026 and 2027.
- Microsoft Learn: Daylight saving time help and support.
- Microsoft Learn: GETDATE (Transact-SQL).
- Microsoft Learn: AT TIME ZONE (Transact-SQL).
- Microsoft Learn: datetimeoffset (Transact-SQL).
- Microsoft Learn: Choose between DateTime, DateOnly, DateTimeOffset, TimeSpan, TimeOnly, and TimeZoneInfo.
Related service: Managed support.
Related future topics
- Testing scheduled jobs across a daylight saving change.
- Storing times in business applications: local time, UTC or offset.
- Checklist for moving scheduled tasks and SQL Server Agent jobs to a new server.
Learning notes
- Windows holds the time zone rules; SQL Server takes its time from Windows.
- Daylight saving creates a missing hour in spring and a repeated hour in autumn.
- Jobs scheduled between 2am and 3am local time are the most exposed.
- UTC avoids daylight saving problems but needs conversion for display.
- Choose a time zone deliberately, match related servers, and check it during migration.
This article was originally published on .