When applying date filters in model‑driven app views, the selected date may shift by one day earlier than intended. This behavior has been reproduced in standard (non‑customized) environments, confirming it is not caused by configuration or custom logic.

A current workaround exists by adjusting Personalization Settings → Time Zone to match the user’s local time. However, this approach is not viable in real-world scenarios where organizations operate across multiple regions.

In the reported scenario:

• Primary business users are located in Europe, requiring the system timezone to align with European operations
• Operational/support teams are located in Asia (UTC+8)
• Changing personalization settings to resolve the issue creates inconsistency for other user groups
• As a result, the workaround introduces operational conflicts rather than resolving the issue.

Problem Statement

• The current behavior creates a functional limitation in multi‑timezone environments, where:
• Date filtering does not consistently reflect the user’s selected value
• Workarounds require compromising system-wide timezone alignment
• Users in different regions experience inconsistent or incorrect results

Suggested Improvements

• Ensure date filtering preserves the exact selected date, regardless of user timezone
• Decouple UI date selection from backend UTC conversion, or make this behavior configurable
• Provide an option to enforce strict “date-only” filtering logic without timezone shifts
• Introduce clearer system handling for multi-timezone user scenarios, where personalization settings alone are insufficient

Business Impact

• Enables accurate filtering across globally distributed teams
• Eliminates reliance on timezone-based workarounds that disrupt other users
• Improves data consistency and trust in system behavior
• Aligns product functionality with real enterprise use cases involving multiple regions