Invalid time zone ID in user profile silently falls back to JVM default

Goal: Confirm whether FusionAuth validates a user profile time zone ID before accepting it, or whether an unrecognized ID silently falls back to the JVM default time zone.

Research context indicates FusionAuth stores internal timestamps in UTC and applies a configured time zone only at presentation layers such as the admin UI and email templates. It also suggests that invalid or unsupported time zone IDs may fall back to the JVM default without returning a validation error, and that time zone changes affect future display only rather than retroactively converting stored historical event timestamps.

Because behavior may vary by FusionAuth version and no public API is documented for returning a JVM-independent list of supported regional time zones, the exact validation behavior and its effect on existing audit records remain unresolved for a specific build.

• Does the FusionAuth API reject an invalid time zone ID on user profile creation or update, or does it accept the value and fall back to the JVM default?
• If a fallback occurs, is it surfaced in the API response, admin UI, or server logs?
• Does changing a user's time zone convert previously stored event timestamps, or only future rendered values?