feat(edge-apps-library): add optional latitude and longitude parameters to getTimeZone

[nicomiguelino]

User description

Summary

• Add optional latitude and longitude parameters to getTimeZone() function
• Allows callers to provide custom coordinates instead of always relying on metadata coordinates
• Maintains backward compatibility (parameters are optional)
• Provides flexibility for testing and use cases where coordinates are known in advance

Changes

• Updated getTimeZone() signature to accept optional latitude?: number, longitude?: number parameters
• Added JSDoc documentation for the new parameters
• Modified coordinate resolution logic to prioritize provided parameters over metadata coordinates

---

PR Type

Enhancement

---

Description

• Add optional coordinates to getTimeZone

• Prefer explicit params over metadata coordinates

• Keep override/UTC fallback behavior unchanged

---

Diagram Walkthrough

flowchart LR
  A["Caller"] 
  B["getTimeZone(latitude?, longitude?)"]
  C["override_timezone setting"]
  D["Provided coordinates"]
  E["Metadata coordinates"]
  F["tzlookup()"]
  G["UTC fallback"]

  A -- "calls" --> B
  B -- "check override" --> C
  B -- "if no valid override" --> D
  D -- "else fallback" --> E
  D -- "resolve coords" --> F
  E -- "resolve coords" --> F
  B -- "on error" --> G

Loading

File Walkthrough

	Relevant files
Enhancement	locale.ts Allow getTimeZone to accept custom coordinates                      edge-apps/edge-apps-library/src/utils/locale.ts Add latitude? and longitude? parameters Document new parameters in JSDoc Use params when provided, else metadata Pass resolved coords into tzlookup +13/-3

---

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Input Validation The new optional latitude/longitude parameters are passed directly to tzlookup(). Consider validating they are finite numbers and within valid ranges (lat: -90..90, lng: -180..180) to avoid unexpected runtime errors or incorrect timezone resolution. export async function getTimeZone( latitude?: number, longitude?: number, ): Promise<string> { Edge Case Coordinate selection only switches to explicit parameters when both are defined. Confirm the intended behavior when callers provide only one of the two values (e.g., should it fall back to metadata as it does now, or should it warn/throw to prevent silent misuse). // Use provided coordinates or fall back to metadata coordinates const [lat, lng] = latitude !== undefined && longitude !== undefined ? [latitude, longitude] : getMetadata().coordinates return tzlookup(lat, lng) Fallback Robustness When metadata coordinates are missing/invalid, destructuring and calling tzlookup() will throw and fall back to UTC. Ensure this is acceptable for callers and consider adding a more explicit warning when neither explicit coordinates nor valid metadata coordinates are available. // Use provided coordinates or fall back to metadata coordinates const [lat, lng] = latitude !== undefined && longitude !== undefined ? [latitude, longitude] : getMetadata().coordinates return tzlookup(lat, lng) } catch (error) { console.warn('Failed to get timezone from coordinates, using UTC:', error) return 'UTC'

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Validate and sanitize coordinates Validate coordinates before passing them to tzlookup to avoid unexpected results or runtime errors when values are NaN, infinite, or out of valid ranges. Also, explicitly ignore partial overrides (only one of latitude/longitude provided) to prevent silently using metadata with a potentially unintended caller input. edge-apps/edge-apps-library/src/utils/locale.ts [92-97] -// Use provided coordinates or fall back to metadata coordinates +const hasLat = typeof latitude === 'number' && Number.isFinite(latitude) +const hasLng = typeof longitude === 'number' && Number.isFinite(longitude) + +if ((hasLat && !hasLng) || (!hasLat && hasLng)) { + console.warn( + 'Partial coordinates provided (latitude/longitude); ignoring override and using metadata coordinates', + ) +} + +// Use provided coordinates only when both are valid numbers; otherwise fall back to metadata coordinates const [lat, lng] = - latitude !== undefined && longitude !== undefined - ? [latitude, longitude] - : getMetadata().coordinates + hasLat && hasLng ? [latitude, longitude] : getMetadata().coordinates + +const latOk = typeof lat === 'number' && Number.isFinite(lat) && lat >= -90 && lat <= 90 +const lngOk = typeof lng === 'number' && Number.isFinite(lng) && lng >= -180 && lng <= 180 +if (!latOk || !lngOk) throw new Error(`Invalid coordinates: lat=${String(lat)} lng=${String(lng)}`) + return tzlookup(lat, lng) Suggestion importance[1-10]: 6 __ Why: Adding finiteness/range checks before calling tzlookup can prevent confusing results when inputs are NaN/infinite/out-of-range, and the “partial override” warning makes caller mistakes more visible. It’s a reasonable robustness improvement, though not critical given the surrounding try/catch already falls back to UTC.	Low