NgRx State Store Limits for Regional Time Zone Normalization

When managing application-wide state in NgRx, there is a design tension between storing date objects in the Store versus normalizing them to UTC strings or timestamps to ensure consistency across different regional time zones.

Storing raw JavaScript Date objects in the state tree can introduce risks regarding immutability and serialization, while converting all dates to UTC within Reducers may shift the responsibility of local time conversion to the UI layer via Selectors.

If the conversion logic is placed in an Effect, the state may temporarily hold inconsistent time formats during the asynchronous transition. If placed in a Selector, the memoization may be bypassed if the user's locale changes dynamically.

• Should time zone normalization occur within the Reducer to maintain a strict UTC source of truth?
• What are the performance implications of performing locale-specific date conversions inside memoized Selectors for large state trees?