Launch Watch · launch_schedule_precision
Published
Why one California launch window spans two UTC dates
Convert a real October 2026 Starlink interval between UTC and California time, keeping both endpoints and the source-read date intact.
The same California launch window can stay entirely on October 10 locally while ending on October 11 in UTC. The date change comes from the clock you use; it does not, by itself, establish a launch delay.
Take the SpaceX Starlink listing read on October 3, 2026. Its four-hour interval converts cleanly between the two clocks. Preserving both endpoints is what makes the record understandable.
This is a frozen source-reading and conversion example, not a current launch alert. For the operator’s schedule, use the SpaceX launch list.
The actual interval in the source record
The directly rendered SpaceX upcoming-launch table read on October 3 listed Starlink Mission, Falcon 9 and SLC-4E, California, with October 10, 2026, 16:00–20:00 PT. The generic mission label did not supply a group number.
A separate search-readable version of the official mission URL displayed October 10 at 23:00 through October 11 at 03:00, GMT+0. That search result was marked as crawled two days earlier. The direct local-time observation and the UTC record agree after conversion.
| Clock | Window starts | Window ends | Elapsed interval |
|---|---|---|---|
| UTC | Oct 10, 2026, 23:00 | Oct 11, 2026, 03:00 | 4 hours |
| California: PDT, UTC−7 | Oct 10, 2026, 16:00 | Oct 10, 2026, 20:00 | 4 hours |
Convert the endpoints, then compare the dates
The calculation uses the named timezone America/Los_Angeles for the scheduled date. Its applicable offset is seven hours behind UTC. Subtract seven hours from each endpoint: 23:00 becomes 16:00 on October 10; 03:00 on October 11 becomes 20:00 on October 10.
Subtracting the two UTC datetimes gives 14,400 seconds, or four hours. The local endpoints represent the same instants, so their interval is also four hours. The conversion changes the calendar labels, not the duration.
Midnight in UTC falls one hour after the start. At that same instant, the California clock reads 17:00 on October 10. This is why a date-only comparison can appear inconsistent even when the underlying schedule is identical.
Does an October 11 UTC ending mean the whole launch is on October 11?
No. This recorded window begins on October 10 in UTC and ends on October 11 in UTC. In California it begins and ends on October 10. A single date without a timezone and endpoint label cannot fully represent this interval.
A schedule card should keep the whole window
For this source record, a useful card would read: “Announced window: October 10, 16:00–20:00 PDT. UTC: October 10, 23:00 to October 11, 03:00. Source read: October 3.” Those three lines preserve the interval, the alternative clock and the age of the source.
A card containing only “October 10, 23:00 UTC” preserves the start but loses the end. A reader cannot recover the four-hour duration from that field alone. Adding a countdown to the opening instant does not restore the missing endpoint or make that instant a guaranteed liftoff time.
The included local data check verifies that both endpoints are present, that the end is later than the start, that the UTC dates differ, and that the California dates match. Removing the end field fails the completeness check. This is a test of the article’s sample record, not a claim that the live LaunchDetect card or its structured data was tested.
Keep window duration separate from flight duration
The four-hour quantity describes the announced launch interval. It says nothing about how long the rocket flies, how long a webcast runs or when deployment occurs. A data model should keep those concepts in separate fields even if a display uses the word “duration” for several of them.
It should also retain the original source label and the retrieval date. Here, “Starlink Mission” is sufficient to identify the row we read when combined with the site and interval, but it is not a unique permanent mission identifier. Assigning a guessed group number would add apparent precision without supporting evidence.
For a launch watch, return to the operator before making plans; an announced interval can change. For an archive or conversion check, keep the original endpoints and the as-of date. That gives the next reader enough information to reproduce the result: one four-hour interval, two UTC dates, and one California evening.