Bug Report: Incorrect Timezone Handling and Backtracking in Neon UI

Issue: The Neon UI incorrectly adjusts and backtracks timestamps stored in UTC, instead of displaying them correctly based on the stored value. Description: This issue started within the past week. The timestamps in our example "ChatMessage" table are stored in UTC, and the SQL editor confirms that they are displayed correctly in UTC when queried. - In the SQL editor: Timestamps are displayed exactly as they are stored in UTC. External connections to the Postgres database further confirm that the timestamps are stored correctly in UTC. - In the Neon UI: The issue arises when viewing these same timestamps. The UI incorrectly adjusts the timestamps based on the user's local timezone and applies the wrong offset. For example, when the system timezone is set to GMT+2 (European time), the timestamp is backtracked by 2 hours (to 07:34) instead of being moved forward by 2 hours (to 11:34), which would be the correct behavior. Steps to Reproduce: 1. Store a timestamp in UTC in any table. 2. Query the table in the SQL editor, confirming that the timestamp is displayed in UTC (as stored). 3. View the same table in the Neon UI. 4. Change the system timezone to a non-UTC timezone (e.g., GMT+2). 5. Observe that the Neon UI incorrectly backtracks the timestamp instead of adjusting it correctly for the local timezone. Additional Notes: - If the system timezone is set to Iceland (GMT+0), the Neon UI correctly displays the timestamps in UTC. - Double-clicking the timestamp in the UI (which shows the local time) correctly reveals the original UTC time, further confirming that the underlying data is correct but the display logic is flawed. Environment: - Operating System: macOS 14.6.1 (23G93) - Browser: Version 128.0.6613.120 (Official version) (arm64) Expected Behavior: The Neon UI should display timestamps stored in UTC as they are, without incorrectly adjusting or backtracking them based on the user's local timezone.