Convert Instant/ZonedDateTime -> Date about proposal-temporal-v2 HOT 2 OPEN

Thanks for this suggestion. Date.fromTemporalInstant(instant) seems like a reasonable addition to the API, and it's consistent with Date.toTemporalInstant(instant) which performs the opposite conversion in the V1 of Temporal.

I'd be concerned about Date.fromTemporalZonedDateTime(zonedDateTime) however, because while gathering community usage experience of Date to inform the design of the Temporal API, we found it to be a surprisingly common mistake made by novice JS developers to assume that Date contains a time zone. Example: https://stackoverflow.com/questions/15141762/how-to-initialize-a-javascript-date-to-a-particular-time-zone

For developers who think Date has a time zone, it'd be logical for them to assume that Date.fromTemporalZonedDateTime(zonedDateTime) carries the time zone from Temporal.ZonedDateTime over to the Date instance. If the Temporal.ZonedDateTime instance had the user's time zone, it might take time to discover the bug because Date appears to have the same time zone.

For this reason, if we do extend Date<=>Temporal.* conversions, I'd recommend that we limit to Temporal.Instant only, in order to help those novice developers learn that converting from Temporal.ZonedDateTime loses the time zone along the way.

from proposal-temporal-v2.

I agree with your assertion that many developers assume that Date has a timezone.

However:

1. Whatever % of developers believe that today, I'm skeptical that the existence of Date.fromTemporalZonedDateTime() would increase it.
2. The purpose of these functions is to interface with legacy Date code. If code relied on Date having a timezone, it will remain just as broken as it was before.

That said, most of the value is achieved by having Date.fromTemporalInstant().

from proposal-temporal-v2.