Date pickers lose time zone when using the calendar after values are cleared

[Stanaland-Michael-bah]

Provide a general summary of the issue here

When a date picker is supplied a ZonedDateTime as a value or defaultValue, if the user clears out the date and/or time value (by either backspacing over the field values or by clicking a "clear dates" button), then choses a new date from the popup calendar, the internal state value looses the time zone information and becomes a CalendarDateTime.

removing.time.mov

removing.date.mov

🤔 Expected Behavior?

The internal state value type should persist regardless of editing (If it starts out as a ZonedDateTime, it should stay a ZonedDateTime)

😯 Current Behavior

See general summary. There is a work-around: If you provide a placeholderValue, the time zone will persist

workaround.mov

💁 Possible Solution

Maybe a similar issue that was fixed in useTimeFieldState here:
https://github.com/adobe/react-spectrum/pull/4715/files

🔦 Context

No response

🖥️ Steps to Reproduce

You can use this fork of the useDatePicker Tailwind CSS example:
https://codesandbox.io/p/sandbox/gifted-vaughan-9n2wfm?file=%2Fsrc%2FApp.js

The only thing that was changed was to swap the DatePicker's defaultValue for an absolute date

1. Backspace over the hours and minutes

2. Open the calendar dialog and choose a new date
   time zone is lost, value becomes a CalendarDateTime

3. Backspace over the year, month and day

4. Open the calendar dialog and choose a new date
   time zone is lost, value becomes a CalendarDateTime

Workaround:

1. Add a placeholderValue that is a ZonedDateTime
2. Repeat the steps above
   time zone persists as expected

Version

"react-stately": "^3.30.1", "react-aria": "^3.32.1",

What browsers are you seeing the problem on?

Firefox, Chrome, Safari, Microsoft Edge

If other, please specify.

No response

What operating system are you using?

MacOS 14.3.1

🧢 Your Company/Team

No response

🕷 Tracking Issue

No response

[LFDanLu]

Thanks for reporting this, reproduced locally. This was partially fixed via #4715, that PR might help point to where we would want to investigate further.

[boutahlilsoufiane]

Hi @LFDanLu I will work on this.

[LFDanLu]

Sure, thanks! Let us know if you need any help or guidance.

[boutahlilsoufiane]

@LFDanLu Could you please check #7069