Twice a year, a camera that records continuously produces an hour that happens twice and an hour that never happens at all. Everything downstream of that — filenames, sort order, retention windows, "how long did it record", and the answer to what did the camera see at half one — is quietly wrong for one night, and nobody notices until they go looking.
This is not an obscure edge case. If you have turned an old Android phone into a always-on camera, you will hit it on the next transition, and the failure is silent. Here is exactly what breaks, and what to do about it.
The two transitions, precisely
In a region that observes daylight saving time, the local wall clock is adjusted twice a year.
Fall back. The clock is set back one hour. In most of the United States that happens at 02:00 local, which becomes 01:00 local. The result is that the local times from 01:00:00 to 01:59:59 occur twice, an hour apart in real time. A recorder that runs through it produces 3600 seconds of footage that all carries a local timestamp already used by an earlier 3600 seconds.
Spring forward. The clock is set ahead one hour. 02:00 local becomes 03:00 local. The local times from 02:00:00 to 02:59:59 do not exist that day. Nothing recorded that night can honestly be labelled 02:30 local.
Real time never skipped or repeated. Only the label did. That distinction is the whole problem.
What actually breaks
1. Filename collisions
Segmented recording — the sane approach for continuous capture, and the one that makes retrieval tractable — names each file after its start time. If that name is built from local wall time, the fall-back hour hands you two different segments that want the same name.
2026-11-01_01-00-00.mp4 <- first pass, offset -04:00
2026-11-01_01-00-00.mp4 <- second pass, offset -05:00, one hour later in real time
There are only three things a writer can do here, and all three are bad in a different way:
- Overwrite. You lose the first pass. An entire hour is gone and there is no error anywhere.
-
Suffix. You get
..._01-00-00 (1).mp4, which survives, but the suffix is not a time and does not sort. - Refuse. The write fails and the gap in coverage is the hour you were most likely to be asleep for.
2. Sort order stops being time order
Sorting a folder by name, or by any local-time field, is only equivalent to sorting by time if local time increases monotonically. Across a fall-back it does not. The second 01:15 sorts before the first 01:45 even though it happened thirty minutes after it. Scroll a file manager on the morning after and the night reads out of order, with no visible sign that anything is unusual.
The same applies to sorting by the metadata clocks — the three that already disagree with each other for unrelated reasons, which I wrote about in Recording Is the Easy Half. DST does not add a fourth clock. It makes each existing one ambiguous.
3. "Show me 01:30" has two answers
This is the one that matters when the footage matters. A retrieval scheme built on wall-clock time — the fastest and most durable one, because the filename is the only index that survives a copy, an uninstall, or a media-store rebuild — resolves a request for a time to a file by arithmetic. On the ambiguous hour, the arithmetic has two solutions and no way to choose. You have to open both.
4. Durations computed from wall time are off by an hour
Subtract two local timestamps that straddle a transition and the result is wrong by exactly 3600 seconds, in one direction in November and the other in March. Anything that reports "recorded for 8 hours" by differencing wall clocks will report 9 or 7 that night.
Wall clock answers when. It is the wrong source for how long. Duration should come from a monotonic source — elapsed-time counters that are not affected by the clock being set — and only be rendered into wall time at the end.
5. Schedules and retention windows change length
A nightly window of 22:00 to 06:00 is eight hours on 363 nights a year. On the fall-back night it is nine. On the spring-forward night it is seven, and the seven does not include 02:00–03:00, because that hour does not exist.
Retention is the same shape. A "keep 7 days" rule is 168 hours normally, 169 across a fall-back and 167 across a spring-forward. Whether that matters depends on how close you were running to the edge of the card. At 4 Mbps a continuous recording is about 1.8 GB per hour; at 8 Mbps, about 3.6 GB. One extra unplanned hour is a couple of gigabytes you did not budget, on the night your delete-oldest policy is already the only thing standing between you and a full card.
2 Mbps -> 0.90 GB/hour
4 Mbps -> 1.80 GB/hour
8 Mbps -> 3.60 GB/hour
16 Mbps -> 7.20 GB/hour
(Bitrate on a phone is usually variable, so treat these as the shape of the number, not a guarantee.)
The other clock problem, which looks identical
A phone that has been repurposed as a camera is often a phone with no SIM, no mobile data, and a wifi connection that is only as good as wherever you mounted it. Automatic date and time on Android comes from the network. A device that cannot reach a time source falls back to its own hardware clock, and hardware clocks drift.
Drift over a weekend is invisible. Drift over the eight weeks a camera runs unattended is not. And the symptom — timestamps that do not match when you know the thing happened — is the same symptom DST produces. If you only look at the file list, you cannot tell a one-hour DST offset from a device that has quietly wandered.
You can tell them apart, though, and it takes ten seconds: a DST error is exactly one hour and applies to everything after the transition. Drift is an arbitrary amount and grows. Check the phone's clock against your own, on the phone, before you conclude anything about the footage.
What to actually do
Store UTC. Render local. UTC has no transitions and no repeats, so it is monotonic and unambiguous — which is exactly what a filename and a sort key need to be. Local time is what a human remembers, so that is what a viewer should display. These are different jobs and one value cannot do both.
If you must name files in local time, put the offset in the name. 01-00-00-0400 and 01-00-00-0500 are different strings, they sort correctly, and they are self-describing a year later. A bare local timestamp is not.
Turn on automatic date and time and confirm the phone can actually reach the network. Half of clock problems on a camera phone are not DST at all.
Get duration from elapsed time, not from subtracting clocks.
When footage leaves the device, state the timezone. This is the practical one. If you are handing a clip to a landlord, an insurer, or a neighbour, "01:30" is not a time — it is a time in a zone, on a day when that zone may have had two of them. Say 01:30 EDT (UTC-4). A timestamp without an offset is a claim, not evidence, and the person receiving it has no way to check it.
Check on the morning after. Open the recordings folder the day after the transition and look at the hour either side of it. That is the only honest test, and it is the only one that will tell you which of the three behaviours above your setup actually has.
Why this is a phone-camera problem specifically
A dedicated camera with a cloud service behind it usually handles this, because the server stores UTC and does the rendering. The trade is well documented and it is not free — a subscription, a vendor that can change retention or shut the product down, and footage that leaves your house.
The local-first version of the setup gives you the footage and the storage and also the timekeeping. That is a real advantage right up until the moment it is a chore, and this is one of the two nights a year it is a chore. The fix is small and it is entirely on your side: name in UTC, display local, put the offset on anything you send. Do it once and the transition stops being an event.
If you are earlier in this than that — still deciding whether an old phone can hold up as a continuous camera at all — the screen-off recording mechanics and the microSD failure modes are the two things worth reading first. Clocks are a problem you get to have only after the recording itself is reliable.
We build Background Camera RemoteStream, a screen-off Android camera and live-stream app that keeps recording locally with the display off. More at superfunicular.com.
Top comments (0)