Repository navigation
feat(trip): deterministic photo ordering and unknown time zones - #40
Conversation
fcd92bb to
0a69ea4
Compare
|
I've integrated this PR on top of #37 (which already includes #38 and #39), resolving the conflicts while preserving the existing API adapters, trip editing, and sharing functionality. I also added a separate fix for trip date aggregation: malformed capture timestamps are now excluded from the trip's start and end dates, using the same validation rules as photo ordering. The regression test covers an invalid February 30 timestamp. The integration preserves the contract-shaped mock API responses, and the Dashboard's recently uploaded photos use the shared ordering utility with the required view-model conversion. |
kctong529
left a comment
There was a problem hiding this comment.
I've completed the review and verification of PR #40.
The ordering rules are consistent with their intended contexts: Trip Gallery and Journey use camera-local capture time (oldest first), while Recently uploaded uses upload time (newest first). Missing and malformed capture timestamps are handled as undated, ties have deterministic ordering, and unknown time zones are presented without inventing an offset.
The integrated implementation passes:
- Type checks and production build
- Lint: 0 errors (36 warnings)
- Full acceptance suite: 301 passed, 2 skipped
- Mock/live boundary tests: 6 passed
- Dedicated photo-ordering tests: 8 checks and 12 browser tests passed
I don't see any remaining blockers within the scope of this PR. The existing lint and bundle-size warnings can be addressed separately.
Approved. Please merge #38, #39, and #37 in that order before merging #40. Once those PRs are merged, retarget this PR to main, verify its final diff and CI checks, and then merge.
44490d2 to
ca385fb
Compare
Use the shared capture-date validation when calculating trip start and end dates, so malformed timestamps cannot affect the displayed date range. Add a regression assertion covering an invalid February 30 timestamp in the photo-ordering acceptance scenario.
0a69ea4 to
a8d2522
Compare
Closes #25 . Capture order (local wall time, oldest first), ties by upload time then photo id; missing or malformed capture times last, in their own "No capture date" group. Recently uploaded is newest upload first. The API is expected to return this order (agreed in #25 ) and the frontend sorts again. "time zone unknown" is shown when no UTC offset was recorded. The viewer follows the order of the view it was opened from.
Suggested new body:
Summary
Implement deterministic photo ordering, explicit handling of unknown capture times and time zones, and consistent photo-viewer navigation.
Implements the frontend portion of #25. Backend contract alignment remains tracked in backend #45 and #47.
Changes
Follow-up correction
Exclude malformed capture dates from trip start/end aggregation using the existing capture-date validation.
Add a regression test covering an invalid February 30 timestamp.
Integration
Rebased onto the integrated frontend branch containing #38 (API adapters), #39 (trip editing), and #37 (mock sharing). Preserve contract-shaped API responses and the existing mock/live separation.
Verification
Remaining work
The backend must implement compatible persistent photo ordering, including stable pagination and missing-timestamp semantics, as part of backend #45/#47 and frontend #19.
Merge order
Merge #38 → #39 → #37 before merging this PR. After those merges, retarget to
mainand verify the final diff and CI checks.