liwenjie200543 commented on code in PR #74011:
URL: https://github.com/apache/airflow/pull/74011#discussion_r4171789883


##########
airflow-core/src/airflow/ui/src/hooks/useDateRangeFilter.ts:
##########
@@ -300,6 +286,30 @@ export const useDateRangeFilter = ({ onChange, translate, 
value }: UseDateRangeF
       });
     };
 
+  const commitEditingState = () => {
+    const { inputs } = editingState;
+
+    if (validateInputs(inputs).length > 0) {
+      return;
+    }
+
+    const nextStartDate = combineDateAndTime(inputs.start, inputs.startTime, {
+      timezone: selectedTimezone,
+    });

Review Comment:
   Good catch — confirmed and fixed in 2e3f01f9.
   
   The inputs were filled in the browser timezone (`dayjs(value).format()`) 
while every commit path (typed edits, calendar picks, and the new 
commit-on-dismiss) interprets them in the selected timezone — so open + close 
re-committed the displayed wall time as if it were in the selected timezone. 
With a Seoul browser and a UTC UI, 01:00 UTC filled as 10:00 and came back as 
10:00 UTC. The same mismatch also affected the calendar-click path, which 
committed browser-local day boundaries.
   
   The fix:
   
   - Fill the inputs (initial state, value-sync effect, and the invalid-input 
blur reset) in the selected timezone, matching the timezone label above them.
   - Commit calendar picks as day boundaries in the selected timezone, so a 
click followed by dismissal re-derives the same value instead of shifting it.
   - Compare at minute granularity on dismissal (the inputs are `HH:mm`), so 
re-deriving an unchanged range — e.g. a calendar-picked 23:59:59.999 end-of-day 
from a displayed 23:59 — no longer fires onChange.
   - The value-sync effect also re-fills the inputs when the selected timezone 
changes.
   
   Three regression tests cover your reported flow (with a browser/UI timezone 
mismatch chosen dynamically so it reproduces on any CI runner), the 
calendar-pick commit, and the parent-synced no-recommit case; all three fail 
without the fix.
   
   One pre-existing nit I left out of scope: the calendar grid/highlight is 
still browser-local, so the highlighted day can differ by one from the inputs 
in cross-timezone setups. Happy to follow up separately if you want it fixed.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to