0

Question: I’m encountering an issue where Mendix widgets (specifically the Date Picker) display date/time values in the browser’s time zone instead of the user’s configured time zone (System.User.TimeZone). I expect the widgets to localize date/time values based on the user’s time zone, as set in the System.User entity, but they seem to rely on the browser’s time zone instead. Below is an example and my setup. Example Scenario: A user in Australia (time zone: "Australia/Sydney", UTC+8) saves a date/time as 2025/01/01 12:00 local time. This is correctly stored in the database as UTC (2025/01/01 04:00Z). When a user with a London time zone ("Europe/London", UTC+1) logs in, but their browser is in Australia (e.g., system clock set to UTC+8), the Date Picker widget should display 2025/01/01 05:00 (UTC+1 localized from 04:00Z). Actual Behavior: The widget shows 2025/01/01 12:00, matching the browser’s time zone (Australia, UTC+8). Additional Note: Using formatDateTime($DateTime, 'yyyy/MM/dd HH:mm') in a microflow correctly returns 2025/01/01 05:00 for the London user, indicating server-side localization works as expected. Context: Our app supports clients with a head office in London and branches in Australia. Users in London need to view and edit Australian branch date/time values in their local time zone (e.g., London time) by setting their System.User.TimeZone to "Europe/London", regardless of their physical location or browser settings. All users have their TimeZone attribute set correctly (e.g., "Europe/London" or "Australia/Sydney") using Olson database IDs, so the app’s default time zone should not apply. The issue occurs in the Date Picker widget for both display and input, showing the browser’s time zone instead of the user’s configured time zone. Setup: Mendix Version: [Specify your version, e.g., 10.24.0, or note if unknown] Widget: Date Picker, configured with format yyyy/MM/dd HH:mm to show date and time. Entity: Contains a DateTime attribute (e.g., Event.EventDateTime), localized = true (default). Time Zones: System.User.TimeZone set to valid Olson IDs (e.g., "Europe/London"). App default time zone set to "Europe/London" in App Settings. Environment: Web app (not native mobile). What I’ve Tried: Verified System.User.TimeZone is set correctly (e.g., "Europe/London") and not empty. Confirmed server-side functions like formatDateTime respect the user’s time zone, returning correct localized values. Tested with different browsers and system time zones to confirm the widget follows the browser’s offset. Questions: Why does the Date Picker widget use the browser’s time zone instead of the user’s System.User.TimeZone for display and input? How can I force the Date Picker to respect the user’s configured time zone (e.g., show 2025/01/01 05:00 for London users, regardless of browser location in Australia)? Are there specific widget settings, microflows, or Marketplace modules (e.g., Date & Time Utilities) to address this? Is this a known limitation in Mendix, and is there a recommended workaround for multi-branch apps with users in different time zones? Additional Details: I suspect the issue is related to client-side rendering in the Date Picker, as server-side formatDateTime works correctly. I’d prefer a solution that keeps the Date Picker for user-friendly date/time input, rather than switching to text inputs. Any guidance on debugging or logging client-side time zone behavior would help. Thank you for any insights or solutions to ensure widgets respect System.User.TimeZone over the browser’s time zone!   Microflow returns user time zone day/date. Widget returns browser time zone date/time.  

asked 2025-09-17

2 answers