Time zones and daylight saving
Last updated: October 28, 2026
The Days Since counter does not ask where you are. It uses the time zone already set on the device, and it starts every count at midnight in that zone. That is enough for one person checking a date on their own phone. It is not enough when two people compare screens, or when the clocks in that zone skip or repeat an hour. This guide is the high-level version of those two cases. It is not a table of every regional rule.
Local midnight, not UTC
When you choose January 1, 2026, the page builds an instant meaning “January 1, 2026 at 00:00:00” in the device’s zone. It does not mean midnight in London, and it does not mean midnight Coordinated Universal Time, unless the device itself is set that way. The elapsed time is “now minus that instant,” and the day figure is how many whole 24-hour blocks fit into the result. The calendar-day guide covers the division. This page covers why the instant moves when the zone moves.
A phone set to India Standard Time, which does not use daylight saving and sits at UTC+5:30, starts January 1 five and a half hours earlier than a phone set to UTC. For a count that began years ago, those five and a half hours are a fraction of a percent of the total. For a count that began yesterday, they can change the hour figure completely, and around midnight they can change the day figure by one. If you expected both phones to match, you were assuming a shared zone the page never stored.
What a share link keeps
Share copies a URL with the calendar date in the d parameter and, if you typed one, the label in the name parameter. It does not copy a time zone, a UTC offset, or a time of day. The person who opens the link counts from midnight in their zone on that calendar date. You might have meant midnight where the event happened. They will not see that unless their device is set to the same zone.
That is a reason to treat the link as a date, not as a synchronized stopwatch. It is also a privacy point: the date and the name are visible in the address. The privacy policy says who can see a URL. It does not claim the link freezes a time zone, because the link has nowhere to put one.
Why the same date can disagree near midnight
Suppose the start date is October 27, 2026. At 11:30 p.m. in New York on October 28, a New York phone has passed one local midnight since October 27 began, and most of another day. A phone in a zone where it is already October 29 has passed an extra midnight. The day figures differ by one. An hour later they may match again, or they may not, depending on the offset. The disagreement is the zones, not a bug that “fixes itself” if you reload. Reloading uses the same zone.
The holiday menu does not remove this. A holiday is still a calendar date. Christmas Day is December 25 in the menu, started at local midnight wherever the device lives. The menu is a list of common U.S. labels, not a claim that the count is locked to U.S. Eastern time.
Daylight saving changes the length of a civil day
In zones that observe daylight saving, one civil day in spring is 23 hours long, because the clocks jump forward, and one civil day in autumn is 25 hours long, because the clocks repeat an hour. The counter does not count civil midnights. It counts elapsed time in 24-hour blocks. After a 23-hour civil day, the day figure lags a midnight-count by about an hour. After a 25-hour civil day, the day figure leads a midnight-count by about an hour. The lag lasts until the missing or extra hour has been absorbed into the remainder. It is not a permanent off-by-one for the rest of the year.
A concrete spring case, for a U.S. zone that still uses the common rule (second Sunday in March, clocks move forward in the 2 a.m. hour): March 1, 2026 is a Sunday, so the second Sunday is March 8, 2026. From local midnight on March 7 to local midnight on March 9, two civil midnights have passed, but only 47 hours of elapsed time, because the civil day that contains the jump is 23 hours. At that second midnight the counter shows 1 day and 23 hours, not 2 days and 0 hours. It reaches 2 days one hour later by the clock. The page does not “correct” this back to 2 days at midnight. Correcting it would mean counting calendar boxes instead of elapsed time, which is a different tool.
A concrete autumn case under the same U.S. rule (first Sunday in November): November 1, 2026 is a Sunday, so the clocks go back that morning. The civil day of the change is 25 hours. A count that starts at local midnight on October 31 and is read at local midnight on November 2 has crossed two midnights and 49 hours. The counter shows 2 days and 1 hour. A person counting midnights says 2 days exactly. Both descriptions are accurate about different quantities.
Other countries move the clocks on other weekends, or not at all. The page does not look up a region. It asks the device for the local interpretation of the date, and the device already knows whether its zone jumped. If the device zone is wrong, the count is wrong in the same direction. Setting the phone to the zone you actually live in is the fix. There is no zone menu on the site to override it.
The hour the event happened
Midnight is a modeling choice so a date-only form has a definite instant. A flight that landed at 6 p.m., a baby born at 4:12 a.m., or a habit you stopped after lunch are all stored as the preceding midnight. The counter then runs early by that many hours. Over a long span the day figure is still the useful part, and the hours are slightly ahead of a true stopwatch. Over a short span, especially “has a full day passed since the event,” the missing clock time dominates. Days Since will not grow a time-of-day field in order to look more precise than the date you were able to enter. If you have an instant, use a clock that stores an instant.
What this guide will not claim
It will not list every daylight-saving transition in the world, and it will not promise that the U.S. weekends used above stay the law. Those weekends are the rule as it stood for 2026 when this page was written. If a legislature moves the date, the device will follow the new rule and this paragraph will need a correction. It will not say that a count “should” be done in UTC. UTC is a clean scale, and it is not the scale of the calendar date you picked. It will not say two share-link viewers must match. They match when their zones and their clocks match.
If a day figure is off by one outside a daylight-saving weekend and outside a zone difference, that is a real bug. Email contact@days-since.app with the date, the device zone, the clock time, and the number on the screen.