A couple of observations involving DateTimePicker + Timezone + DST changes. Using v8.3.9. Expect "Scenario 1" described below might be difficult to address; somewhat by design, and can at least work around by using formattedValue. "Scenario 2" is probably more definitively a bug, and I think there are other permutations but haven't found a repeatable process. Attached a minimal Perspective View as .zip if it helps to replicate.
Timezone change doesn't affect value of DateTimePicker. Change of date to/from period of DST does change internal value of DateTimePicker +/- 1hr, to maintain the displayed HH:MM component in relative local time. Interaction with timezone changes creates some unexpected results as the additional hour doesn't appear to be handled in quite the same way as base timezone difference.
Both scenarios described are very much edge conditions not expected to hit in actual production, but DST has been an ongoing sore point in our previous MES, so is under close scrutiny. Using UTC exclusively in database and that's fine, but we've facilities and support teams across multiple timezones so we need to present values in the local timezone of the caller to reduce confusion. Presentation of static values from that database has been perfect.
Described scenarios switch between two IANA timezones, one that does observe DST and another that doesn't. Demo: "Pacific/Auckland" as DST observer (UTC+12/+13) and "Australia/Brisbane" (UTC+10) as non-DST observer. DST ended 5th April 2026.
Scenario 1: DateTimePicker value increment/decrement. Repeated cycles can continuously increment. Becomes problematic if component is configured as pickerType=date, where visibility of the incremented hours component is hidden but can still feed into a query, and can have an impact on the date portion if it indexes backwards a day. Can work around by using formattedValue with HH:MM:SS removed but then handling a String rather than Date.
- Select timezone that doesn't observe DST ("Australia/Brisbane"), on a date that other timezone does (2nd April 2026). Clock set to midnight in that timezone.
- Select DST observing timezone.
- Select date after DST ends (8th April 2026). DateTimePicker retains DST offset +3.
- Select non-DST observing timezone. DateTimePicker only subtracts relative timezone difference at that date: -2. DateTimePicker has incremented itself net +1 hour. Reversing order of operations can decrement value.
Scenario 2: Outlined date desync. Same steps can desync outline on 1st of any month, but the DST end interaction is interesting.
- Select 1st April 2026, midnight of greater timezone ("Pacific/Auckland")
- Switch timezone to lesser timezone offset ("Australia/Brisbane"). DateTimePicker goes to previous month, expected due to relative -3hr timezone difference during DST.
- Go forward to April, select any date.
- Switch back to greater timezone ("Pacific/Auckland").
- Internal value of DateTimePicker appears to correctly reflect clicked date, but outline is not synchronised highlighting the day previous for 1st-4th April. (For other months, all dates offset to previous day)
- Select 5th April (date of DST end for "Pacific/Auckland"). DateTimePicker outlines both 4th and 5th April.
- Selecting dates beyond end of DST outline is temporarily in sync.
- Switching month forward/backwards gets outline fully back in sync.
Demo.zip (17.5 KB)
