Understanding DayLight Savings Time (DST)

As a newcomer in IT, I was surprised when my senior said, “Our meetings with the foreign client will now be an hour earlier due to DST.” I had never heard of DST before! This conversation made me realize how Daylight Saving Time (DST) can affect software applications and scheduling.

DST is when we change our clocks to make better use of daylight. This means that twice a year, we either move the clock forward or back, which can cause confusion in software systems.
How DST Changes the Day

DST creates unusual days that are not the standard 24 hours:

Spring Forward (23-Hour Day)

    Clocks skip one hour. For example, at 2:00 AM, the clock jumps to 3:00 AM.

    This means that 2:30 AM never happens, making that day only 23 hours long.

Fall Back (25-Hour Day)

    Clocks go back one hour. For instance, at 2:00 AM, the clock goes back to 1:00 AM.

    This means that 2:30 AM happens twice, creating a day that is 25 hours long.

These changes can cause problems for software systems that rely on local time for scheduling tasks.
The Risks of DST in Software

DST can lead to unexpected issues in software systems, especially with scheduled tasks:
Scenario 1: Duplicate Payments

Imagine you have a payment job set to run at 2:00 AM on the last day of the month. If that day has a Fall Back change:

The clock moves back to 2:00 AM again.

Your payment job might run twice, causing duplicate payments.

Scenario 2: Incorrect Time Display

If your app shows “2 hours ago,” but uses local time:

During Spring Forward, it might show "3 hours ago" instead of "2 hours ago."

During Fall Back, it might show "1 hour ago" instead of "2 hours ago."

These mistakes happen because local time changes with DST, making it unreliable for accurate calculations.
Why UTC is the Best Choice

Coordinated Universal Time (UTC) does not change with DST, making it a reliable option for scheduling tasks. By using UTC:

Jobs will always run at the same time, regardless of local time changes.

Timestamps remain consistent and unaffected by DST shifts.

Example

If you schedule a job at 2:30 AM UTC, it will run at that exact time no matter where your server is located or if there are any DST changes.
Best Practices for Developers

To avoid issues caused by DST, follow these tips:

Store Timestamps in UTC: Always save timestamps in UTC in your database and convert them to local time only when showing them to users.

Schedule Jobs in UTC: Use UTC for all scheduled tasks to ensure they run consistently without being affected by DST.