fix: globe aware custom path and date format in user preference

[idunwannagotoschool]

Fix #643. Fix #651.

Interpolating coordinates along great circle with turf.js, and flatten when returns MultiLineString when crossing antimeridian.

Pass user preferences to the function used to display the date, similar to the preview.svelte. Does fix the panel but not 100% sure it fixes tooltip as I cannot invoke it.

Before:

After:

Note

Fix globe-aware custom path rendering and apply user date format preferences across flight UI

• Updates unwrapTrackPath in flight-layer-data.ts to insert great-circle arc interpolation between successive coordinates that differ by more than 3 degrees, producing smoother paths before longitude unwrapping.
• Extends formatAsFlightDate and related helpers in format.ts to accept user date preferences, routing formatting through localeForDateFormat (now exported from preferences/format.ts).
• Propagates user prefs into every formatAsFlightDate call site across map popups, flight cards, route details, airport detail cards, and the deduplicate tool.
• Behavioral Change: flight dates throughout the UI now render in the user's configured date format/locale instead of the system default.

^{Macroscope summarized c5f0cd9.}

[github-actions]

Label error. Requires exactly 1 of: changelog:.*. Found: Web

[macroscopeapp]

🟡 Medium map/flight-layer-data.ts:56

For interpolated segments, the final interpolated coordinate overwrites the original destination point's altitude with prev[2]. When greatCircle returns the endpoint as its last coordinate, arcCoords.slice(1).map(...) replaces curr's altitude value with the previous point's altitude, silently corrupting track altitude data on long or sparse segments. Consider preserving curr as the final coordinate of each interpolated segment instead of using the last arc coordinate.

-        const interpolatedArcCoords = arcCoords.slice(1).map((coord) => {
-          return prev[2] !== undefined ? [coord[0], coord[1], prev[2]] : coord;
-        }) as FlightTrackCoordinate[];
+        const interpolatedArcCoords = arcCoords.slice(1, -1).map((coord) =>
+          prev[2] !== undefined ? [coord[0], coord[1], prev[2]] : coord,
+        ) as FlightTrackCoordinate[];
+        interpolatedArcCoords.push(curr);

🤖 Copy this AI Prompt to have your agent fix this:

In file @src/lib/map/flight-layer-data.ts around lines 56-58:

For interpolated segments, the final interpolated coordinate overwrites the original destination point's altitude with `prev[2]`. When `greatCircle` returns the endpoint as its last coordinate, `arcCoords.slice(1).map(...)` replaces `curr`'s altitude value with the previous point's altitude, silently corrupting track altitude data on long or sparse segments. Consider preserving `curr` as the final coordinate of each interpolated segment instead of using the last arc coordinate.

[macroscopeapp]

🟡 Medium datetime/format.ts:39

formatAsFlightDate now derives the locale from prefs.dateFormat, passing values like en-GB, en-US, or en-CA into Intl.DateTimeFormat. This forces English month names (Jan, May, etc.) on users whose browser locale is non-English, even though dateFormat only controls field ordering. The month and day cases render short month names via Intl.DateTimeFormat, so any non-English user selecting eu/us/iso loses localized month names in flight dates. Consider using the user's runtime locale for formatting and applying dateFormat only to control field order, or document this as intentional if English is always desired.

🤖 Copy this AI Prompt to have your agent fix this:

In file @src/lib/utils/datetime/format.ts around line 39:

`formatAsFlightDate` now derives the `locale` from `prefs.dateFormat`, passing values like `en-GB`, `en-US`, or `en-CA` into `Intl.DateTimeFormat`. This forces English month names (`Jan`, `May`, etc.) on users whose browser locale is non-English, even though `dateFormat` only controls field ordering. The `month` and `day` cases render short month names via `Intl.DateTimeFormat`, so any non-English user selecting `eu`/`us`/`iso` loses localized month names in flight dates. Consider using the user's runtime locale for formatting and applying `dateFormat` only to control field order, or document this as intentional if English is always desired.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud