feat: added secondary alphabetical sort on timezone selector

[Klakurka]

Description

The secondary sort is seemingly random after the UTC hour on the timezone selector (/account page) so this fixes that.

Test plan

Go to /account and see that we're sorting alphabetically on timezones with the same UTC hour offset.

Summary by CodeRabbit

• Refactor
  • Updated the timezone selector component's internal implementation to improve performance and maintainability while preserving the same user experience and functionality.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

The timezone selector component was refactored to replace the react-timezone-select library with react-select, introducing a custom hook for timezone management, sorted options, and updated prop conventions while maintaining the same public API.

Changes

Cohort / File(s)	Summary
Timezone Selector Library Refactor components/Timezone Selector/index.tsx	Replaced react-timezone-select with react-select; introduced useTimezoneSelect hook to manage all timezones; added useMemo to compute and sort timezone options by offset then name; updated prop names (disabled → isDisabled); modified value handling through parseTimezone function
Dependency Updates package.json	Updated dependencies to reflect library swap from react-timezone-select to react-select

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Focus areas:
  • Verify parseTimezone function correctly transforms timezone values for the new Select component
  • Confirm the sorting logic (by offset, then by name) matches intended UX behavior
  • Validate that useTimezoneSelect hook properly retrieves and exposes all timezone options
  • Test integration with existing parent components to ensure no functional regression despite library change

Poem

🐰 From timezone select old to new we hop,
With react-select, our options won't stop,
Sorted by offset, a tidy display,
The selector now hops in a cleaner way! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main change: adding a secondary alphabetical sort to the timezone selector, which aligns with the code changes switching to a sortedOptions list.
Description check	✅ Passed	The description includes the required sections (Description and Test plan) with sufficient context about the problem being solved and clear instructions for testing the fix.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/better-timezone-selection-sort

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

components/Timezone Selector/index.tsx (1)

6-11: Remove unused props from the interface or implement their functionality.

The interface declares onChange, label, and isEditable props, but line 13 only destructures value. These props are never used:

• onChange: The component uses an internal handleChange that makes direct API calls instead of calling this prop
• label: Never referenced in the component
• isEditable: Never used; isDisabled is hardcoded to false on line 78

This creates a misleading API where consumers might pass these props expecting them to control component behavior.

🔎 Proposed fix: Remove unused props from interface

 interface TimezoneSelectorProps {
   value: string
-  onChange: (value: string) => void
-  label?: string
-  isEditable?: boolean
 }

Or implement the prop functionality if they're intended to be used.

📜 Review details

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a1a64e6 and 122c607.

📒 Files selected for processing (1)

• components/Timezone Selector/index.tsx (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Run Tests

🔇 Additional comments (4)

components/Timezone Selector/index.tsx (4)

76-76: No changes needed. The parseTimezone function from useTimezoneSelect is typed to return ITimezoneOption, and the value prop accepts either a string or ITimezoneOption. The usage at line 76 is correct and compatible with react-select.

---

18-18: No changes needed – displayValue: 'UTC' is a valid and documented option.

The displayValue prop accepts 'GMT' or 'UTC' as valid values, and the current implementation using displayValue: 'UTC' is correct and achieves the intended formatting of timezone labels.

---

20-26: Sorting logic is correct.

The secondary alphabetical sort uses a.value.localeCompare(b.value), which correctly sorts by the timezone identifier (e.g., "America/Juneau", "Europe/Berlin") rather than the formatted display label. The implementation properly:

• Creates a copy of the options array to avoid mutation
• Uses nullish coalescing for defensive handling of undefined offsets
• Applies localeCompare for proper internationalization support in alphabetical ordering

---

1-3: The implementation approach is intentional and supported by the library design.

By default, react-timezone-select uses react-select as its underlying select component. The library explicitly provides a useTimezoneSelect hook to decouple the component from the react-select dependency, enabling developers to use the hook's timezone utilities with external Select components. The useTimezoneSelect hook is documented with examples showing it can work with native select elements or custom implementations, including react-select. This is not an unconventional approach—it's a supported design pattern provided by the library.