Checking its API, I'm surprised that Temporal.Duration has a constructor with many parameters for years, months, days, ... all the way to nanoseconds, while Temporal.Instant has no way at all to create it given a current year/month/day, only from unix timestamp equivalents (or strings)

That seems to be functionality you'd want to have? Or is the intention you convert your numbers to string first and then back to a Temporal.Instant?

It's perfectly reasonable to default seconds, minutes, hours, etc. to zero in the Duration constructor. But for Instant, it doesn't make sense to default those to zero unless you specify time zone offset.

And indeed, the static method Instant.from does accept an RFC 9557 string, which requires a 2-digit hour and a time zone offset, but can omit minutes and seconds:

Temporal.Instant.from("2026-01-12T00+08:00")

I guess they don’t want people getting confused between local and UTC values for the fields in the constructor (especially as if it took local values it would need to handle DST transitions)

it's because a year/month/date isn't enough to uniquely identify an instant in time. you can create a Temporal.PlainDate(Time) with those values though, then convert to the other types depending on what you need and it needs (e.g. time zone)