Keep the last train on the correct service day
A Saturday service departing after midnight appears under Sunday and disappears from the late-night search. The feed expresses service-day times beyond 24:00.
- Focused work estimate
- 2h 45m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Time zones · Domain modeling · Boundary testing
Estimated field mix
- Mobile80%
- Integrations20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
The fictional Northline commuter app plans bus and rail trips from synthetic timetable and alert feeds. Riders save journeys and choose optional reminders. The scope excludes ticket purchases, safety guarantees, and continuous location collection.
Setup prerequisites
- Synthetic timetable with explicit time zones and service dates
- Departure, alert, and permission adapters with failure fixtures
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Service date and elapsed service-day time map to an instant using the feed time zone.
- Display uses rider-friendly local date/time while retaining the original service identity.
- Unsupported or ambiguous feed times produce an explicit data error rather than a guessed departure.
Implementation constraints
- Write the conversion policy for daylight-saving transitions; do not parse service times as ordinary clock-only strings.
Verification to include
- Resolve a Saturday 25:10 service to the expected next-calendar-day instant and keep Saturday service identity.
- Exercise the agreed clock-change fixtures and malformed time input; no negative journey duration or silent guess appears.
Deliverables
- Service-time conversion module and boundary fixture table
Rollout and recovery
Compare converted times against curated synthetic examples; hide affected feed entries if conversion fails.
Value of the work
For the engineer: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design.
For the team: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.