Justin Grant

Another constructor/factory use case I was remind of today is conversion from `BigInt` to `Number`. Here's one example where shaving a few characters prevents Prettier from wrapping to multiple lines,...

> explicit conversion idioms (`+foo` and `""+foo`) FYI, these idioms are challenging for Temporal objects. `""+foo`, will throw if `foo` is a Temporal object because `valueOf` [throws](https://github.com/tc39/proposal-temporal/issues/1681#issuecomment-896344812). Is there another...

Glad we're making these changes to enforce type safety. Thanks for pushing this.

Note that the time zones (unlike the other things that `Intl.supportedValuesOf` enumerates) also live in 262, because non-UTC IANA time zones (and hence the need to canonicalize them) can exist...

> * `datetime`, `plaindatetime`, `date_time`, `plain_date_time` I'd suggest avoiding `datetime` nor `date_time`. Timezone-less date/time types are prone to bugs caused by programmers assuming that the offset will not change. By...

> I know this is EXTREMELY semantic, but I'd ideally like to have one unified approach for temporal_rs. Was there ever any discussion regarding whether a `PlainDateTime` could be interpreted...

Hi - I'm one of the Temporal proposal's champions on TC39. I agree with @hi-ogawa that using `Temporal.Instant` is good (and `Temporal.PlainDateTime` is bad) in this context, for exactly the...

Yep. Given that `Temporal.ZonedDateTime` is never ambiguous and (for purposes of `Date`-compatibility) has the identical `epochMilliseconds` / `epochNanoseconds` API, is there any reason to not accept both types?

> Could you explain what are the use cases for Temporal to support case 3 and 4? There are two general principles used throughout Temporal that apply here: * a)...

> are you saying you need it to be shortern to > > ``` > xmas.toLocaleString("ru", {timeZone: zdt, calendar: zdt}); > ``` Yes, that's case 4. Case 3 is this:...