The Mystery of the 23-Hour Day: Understanding Daylight Saving Time in Weather Data

March 3, 2026

If you’ve ever looked at your weather data on a specific Sunday in March or November and noticed that a day seems to have “lost” or “gained” an hour, you aren’t alone. Every year, our support inbox sees a spike in questions: “Why does the API return 23 hours for March 10th?” or “Is it a bug that there are 25 hours in my CSV?”

The short answer: It’s not a bug—it’s Earth’s (and politics’) way of keeping time.

In this post, we’ll explain why Daylight Saving Time (DST) affects your weather data and how you can manage it using the Visual Crossing Timeline API.

Why the Hour Count Changes

By default, the Visual Crossing Weather API returns data in the local time of the location you are requesting. This is usually exactly what users want; if you are looking for the temperature at “9:00 AM in London,” you want the actual clock time in London.

However, because many countries shift their clocks to maximize daylight, “local time” is not a constant 24-hour cycle.

  1. The “Short” Day (Spring Forward): When a region enters DST, the clock typically jumps from 1:59 AM to 3:00 AM. Because the hour of 2:00 AM never technically existed, the API returns 23 hourly records.
  2. The “Long” Day (Fall Back): When a region leaves DST, the clock jumps back from 1:59 AM to 1:00 AM (in the US and some countries). The hour between 1:00 and 2:00 occurs twice, resulting in 25 hourly records. In other countries, the fall back may occur at other times, typically in the earlier morning such as a repeated 2am or 3am hour.

How to Handle Daylight Saving in Weather API Responses

If your application displays data to end-users (like a mobile app or a dashboard), you likely need to use local time. To do this successfully, your code must be flexible enough to handle the “anomalies” that occur twice a year.

1. Expect Inconsistent Day Lengths

During DST transitions, a single calendar date will not always have 24 hourly records.

  • Spring Forward: The day is 23 hours long.
  • Fall Back: The day is 25 hours long.

Avoid using fixed-length arrays (e.g., new hour[24]). Instead, use dynamic lists or collections that can expand to 25 or contract to 23 without throwing an “index out of bounds” error.

2. Beware of Repeated Datetime Values

During the Autumn “Fall Back” transition, the clock repeats an hour. This creates a trap for your data structures.

In the Timeline Weather API, the datetime field is a local string (e.g., 01:00). On a 25-hour day, this string will appear twice.

  • The Risk: If you use the datetime string as a key in a Map, Dictionary, or Set, the second “1:00 AM” will overwrite the first one. You will lose an hour of weather data.
  • The Fix: Use datetimeEpoch. This value is based on UTC and is always unique, even during a local time overlap. Use the epoch as your unique ID and the string only for display.

3. Streamlining Data Analysis: Using UTC for Consistency

If you are building machine learning models or performing long-term time-series analysis, local clock shifts are usually a nuisance rather than a requirement. You can bypass the DST headache entirely by forcing the API into Coordinated Universal Time (UTC).

By adding the timezone parameter to your request: &timezone=Z (where ‘Z’ stands for Zulu/UTC time)

When this is enabled, every single day in your dataset will contain exactly 24 unique hours. This ensures your data remains perfectly linear and easy to process without complex logic for specific Sundays in March or November.

Daylight Saving Around the Globe

Daylight Saving Time is notoriously inconsistent. Not only do the dates change every year, but different regions use different names and schedules. Here are some common examples to watch out for:

United States & Canada

  • Common Name: Daylight Saving Time (DST)
  • Typical Schedule: Starts the second Sunday in March; Ends the first Sunday in November.
  • Note: Most of Arizona and Hawaii do not observe DST.

United Kingdom

  • Common Name: British Summer Time (BST)
  • Typical Schedule: Starts the last Sunday in March; Ends the last Sunday in October.
  • Standard Time Name: Greenwich Mean Time (GMT).

European Union (EU)

  • Common Name: Central European Summer Time (CEST), Eastern European Summer Time (EEST), etc.
  • Typical Schedule: Synchronized across the EU to start the last Sunday in March and end the last Sunday in October.

Australia

  • Common Names: Australian Eastern Daylight Time (AEDT), Australian Central Daylight Time (ACDT).
  • Typical Schedule: Starts the first Sunday in October; Ends the first Sunday in April.
  • Participating Regions: New South Wales, Victoria, South Australia, Tasmania, and the Australian Capital Territory.
  • Non-Participating Regions: Queensland, Western Australia, and the Northern Territory remain on standard time year-round.
  • The “Half-Hour” Exception: Lord Howe Island is unique—it only shifts its clock by 30 minutes during DST transitions (moving from UTC+10:30 to UTC+11)

Summary

If you see 23 or 25 hours in your weather data, your API integration is working exactly as it should—it is reflecting the reality of the local clock. While it might look like a data error, these shifts are mandated by regional laws—such as the U.S. Uniform Time Act and EU Directive 2000/84/EC. Following the W3C best practice of using UTC can help you avoid these local clock complexities entirely.

If your workflow prefers consistency over local clock accuracy, simply use the timezone=Z parameter to switch to UTC. For more tips on getting the most out of your weather data, check out our full documentation.