parkhojeong commented on code in PR #66251:
URL: https://github.com/apache/airflow/pull/66251#discussion_r3236394646
##########
airflow-core/src/airflow/ui/src/components/DateTimeInput.tsx:
##########
@@ -54,16 +54,43 @@ export const DateTimeInput = forwardRef<HTMLInputElement,
Props>(({ onChange, va
debounceDelay,
);
+ const onPaste = (event: ClipboardEvent<HTMLInputElement>) => {
+ const pasted = event.clipboardData.getData("text").trim();
+ // Pasted strings with an explicit timezone (e.g. `Z` or `+09:00`) are
parsed
+ // as their absolute instant. Strings without one are treated as being in
the
+ // selected Airflow UI timezone — consistent with manual input.
+ const hasExplicitTz = /(?:[Zz]|[+-]\d{2}:?\d{2})$/u.test(pasted);
+ const parsed = hasExplicitTz ? dayjs(pasted) : dayjs.tz(pasted,
selectedTimezone);
+
+ if (!parsed.isValid()) {
+ return;
+ }
+
+ event.preventDefault();
+ // datetime-local input requires YYYY-MM-DDTHH:mm format in the selected
+ // Airflow UI timezone (not the browser's local timezone).
+ const localFormat = parsed.tz(selectedTimezone).format("YYYY-MM-DDTHH:mm");
+
+ // Drop any debounced call queued by prior typing so it cannot fire after
+ // this paste and trigger a redundant onChange on the parent form.
+ debouncedOnDateChange.cancel();
+ onDateChange({
+ ...event,
+ target: { ...event.currentTarget, value: localFormat },
+ });
+ // Override the display set by onDateChange (which uses
DEFAULT_DATETIME_FORMAT)
+ // so the datetime-local input keeps the YYYY-MM-DDTHH:mm format it
requires.
+ setDisplayDate(localFormat);
Review Comment:
onPaste reuses onDateChange to emit the normalized UTC value, but that also
causes displayDate to be set once with DEFAULT_DATETIME_FORMAT and then
immediately overwritten with the datetime-local format. This seems to rely on
the second update winning. Could we split the emit logic from the display
update so paste avoids the invalid intermediate value?
##########
airflow-core/src/airflow/ui/src/components/DateTimeInput.tsx:
##########
@@ -54,16 +54,43 @@ export const DateTimeInput = forwardRef<HTMLInputElement,
Props>(({ onChange, va
debounceDelay,
);
+ const onPaste = (event: ClipboardEvent<HTMLInputElement>) => {
+ const pasted = event.clipboardData.getData("text").trim();
+ // Pasted strings with an explicit timezone (e.g. `Z` or `+09:00`) are
parsed
+ // as their absolute instant. Strings without one are treated as being in
the
+ // selected Airflow UI timezone — consistent with manual input.
+ const hasExplicitTz = /(?:[Zz]|[+-]\d{2}:?\d{2})$/u.test(pasted);
+ const parsed = hasExplicitTz ? dayjs(pasted) : dayjs.tz(pasted,
selectedTimezone);
+
+ if (!parsed.isValid()) {
+ return;
+ }
+
+ event.preventDefault();
+ // datetime-local input requires YYYY-MM-DDTHH:mm format in the selected
+ // Airflow UI timezone (not the browser's local timezone).
+ const localFormat = parsed.tz(selectedTimezone).format("YYYY-MM-DDTHH:mm");
+
+ // Drop any debounced call queued by prior typing so it cannot fire after
+ // this paste and trigger a redundant onChange on the parent form.
+ debouncedOnDateChange.cancel();
+ onDateChange({
+ ...event,
+ target: { ...event.currentTarget, value: localFormat },
+ });
+ // Override the display set by onDateChange (which uses
DEFAULT_DATETIME_FORMAT)
+ // so the datetime-local input keeps the YYYY-MM-DDTHH:mm format it
requires.
+ setDisplayDate(localFormat);
Review Comment:
onPaste reuses onDateChange to emit the normalized UTC value, but that also
causes displayDate to be set once with DEFAULT_DATETIME_FORMAT and then
immediately overwritten with the datetime-local format.
This seems to rely on the second update winning. Could we split the emit
logic from the display update so paste avoids the invalid intermediate value?
--
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]
