How to Find Time Zone Bugs in C# Applications

Use the Correct Model for Scheduled Jobs

A timestamp and a recurring schedule are not the same thing.

Consider two requirements:

• Run a background job every 24 hours.

• Run a report at 9:00 AM every weekday in London.

The first requirement can be based on elapsed time. The second depends on a regional wall-clock time and its time zone rules.

If the application schedules the second job by repeatedly adding 24 hours, the execution time may shift when the region changes its clocks.

Store recurring schedules using the local time, the relevant time zone identifier, and the recurrence rules. When calculating the next execution, use the time zone's rules to resolve the intended instant.

For example, a scheduling model could contain:

public sealed class ScheduledJob
{
    public string JobName { get; set; } = string.Empty;

    public TimeOnly LocalStartTime { get; set; }

    public string TimeZoneId { get; set; } =
        "Europe/London";

    public DayOfWeek[] RunDays { get; set; } =
        Array.Empty<DayOfWeek>();
}

This model describes a schedule rather than a single instant. A production scheduler must still calculate the next occurrence, handle daylight saving transitions, and define what happens when a scheduled time is invalid or ambiguous.

For a one-time appointment, you may need both the intended local time and the time zone, along with the resolved instant. This is useful when the original appointment details must remain visible even if time zone rules change later.

Find Common Time Zone Bugs in Existing Code

When investigating an application, search for patterns that often indicate incorrect time handling.

Using DateTime.Now for persisted events

DateTime.Now returns the machine's local time. If the server's time zone changes between development and production, the resulting values may be interpreted differently.

For event timestamps, prefer DateTimeOffset.UtcNow or DateTime.UtcNow, depending on the application's data model.

Calling ToUniversalTime on an Unspecified value

Consider this code:

DateTime appointment = new DateTime(
    2026, 10, 25, 9, 0, 0);

DateTime utcAppointment =
    appointment.ToUniversalTime();

Because the value has DateTimeKind.Unspecified, ToUniversalTime() interprets it using the machine's local time zone. If the appointment was intended to be 9:00 AM in another region, the result may be wrong.

Instead, identify the appointment's actual time zone and convert explicitly:

DateTime localAppointment = new DateTime(
    2026, 10, 25, 9, 0, 0,
    DateTimeKind.Unspecified);

TimeZoneInfo appointmentZone =
    TimeZoneInfo.FindSystemTimeZoneById(
        "Europe/London");

if (appointmentZone.IsInvalidTime(localAppointment))
{
    throw new InvalidOperationException(
        "The appointment time does not exist.");
}

if (appointmentZone.IsAmbiguousTime(localAppointment))
{
    throw new InvalidOperationException(
        "The appointment time requires an ambiguity policy.");
}

DateTime utcAppointment =
    TimeZoneInfo.ConvertTimeToUtc(
        localAppointment,
        appointmentZone);

This version deliberately rejects ambiguous times until the application defines how to resolve them. A production application can replace the exception with its approved scheduling policy.

Comparing dates without considering their meaning

Comparing two values that represent different time zones or have inconsistent DateTimeKind values can produce misleading results.

Before comparing dates, determine whether you are comparing instants, calendar dates, or local wall-clock values. Convert instants to a consistent representation before comparing them.

If the requirement is to determine whether two events occurred in chronological order, compare their UTC instants. If the requirement is to determine whether an appointment falls on a particular local date, evaluate it in the relevant time zone.

Using a fixed UTC offset

A fixed offset such as UTC+01:00 is not a substitute for a regional time zone. A region may use different offsets at different times of the year.

Use TimeZoneInfo for conversions that depend on regional rules.

Write Tests That Expose Time Zone Bugs

A test suite that runs only on one machine configuration may miss problems that appear in production.

Include tests for:

• UTC timestamps and their local representations.

• Dates near midnight, when conversion may change the calendar date.

• Daylight saving transitions.

• Invalid and ambiguous local times.

• Servers configured with different local time zones.

• Serialization and deserialization of DateTime and DateTimeOffset.

• Database round trips that preserve the intended timestamp.

• Recurring jobs that must run at a specific local time.

For example, a simple test can verify that a timestamp converts to the expected local representation:

using Xunit;

public class TimeZoneTests
{
    [Fact]
    public void ConvertsUtcTimeToIndiaTime()
    {
        var utcTime = new DateTimeOffset(
            2026, 10, 15, 4, 0, 0,
            TimeSpan.Zero);

        var indiaZone =
            TimeZoneInfo.FindSystemTimeZoneById(
                "Asia/Kolkata");

        var localTime = TimeZoneInfo.ConvertTime(
            utcTime,
            indiaZone);

        Assert.Equal(9, localTime.Hour);
        Assert.Equal(30, localTime.Minute);
        Assert.Equal(TimeSpan.FromHours(5.5),
            localTime.Offset);
    }
}

The expected result is 9:30 AM at UTC+05:30. The test checks both the clock time and the offset.

For tests involving regional daylight saving rules, select dates where the expected behavior is known and ensure the relevant time zone data is available in the test environment. Avoid relying on the machine's local time zone, because that can make tests behave differently across developers' computers and CI servers.

Best Practices for Reliable Date and Time Handling

Use the following guidelines when designing C# applications:

• Use DateTimeOffset for event timestamps that identify a specific instant.

• Use UTC consistently for persisted event timestamps when that fits your database and application design.

• Store a regional time zone identifier when a business rule depends on local time.

• Use DateTimeKind.Unspecified carefully for wall-clock values that must be interpreted in a separately identified time zone.

• Use TimeZoneInfo instead of manually adding or subtracting hours.

• Define explicit rules for invalid and ambiguous local times.

• Test date conversion and serialization across different environments.

• Keep recurring schedules separate from individual event timestamps.

Also consider that time zone rules can change when governments change their policies. Systems that schedule events far into the future may need to recalculate future occurrences when their time zone data is updated.

Conclusion

Most time zone bugs begin when an application stores or converts a date without preserving what that value means. A local appointment, a UTC timestamp, and a recurring schedule are different kinds of data and should not be handled interchangeably.

Use DateTimeOffset for actual instants, UTC for consistent event storage, and TimeZoneInfo for regional conversions. For scheduled jobs and appointments, preserve the intended time zone and define how daylight saving transitions should be handled.

These practices make C# applications more reliable across servers, databases, users, and regions.