Decide TypeScript type of ZonedDateTime.prototype.timeZone

[ptomato]

Follow-up from #1037/#810.

The current type of the ZonedDateTime.prototype.timeZone property is TimeZoneProtocol in the TypeScript bindings. This is annoying because the methods in the protocol are optional, and so you have to write an extra as Temporal.TimeZone to deal with it in the 99.9% case, whereas the case where you have purposely introduced a TimeZoneProtocol object without all the methods is very rare. But on the other hand, leaving it as-is leaves maximal choice for the code author.

[ryzokuken]

Wait, don't all Temporal.TimeZone objects implement the TimeZoneProtocol interface?

[ptomato]

They do! But not all objects implementing the TimeZoneProtocol interface have all the methods of Temporal.TimeZone.

[justingrant]

Wait, don't all Temporal.TimeZone objects implement the TimeZoneProtocol interface?

They do. The problem is that most of the properties and members are optional, which means that anyone using .id, .getOffsetString(), or any of the other optional methods will get a compiler error. The error can be overridden with a type cast e.g. foo as TimeZone, but requiring an extra 15-character type cast on methods that will essentially always be implemented is confusing the first time and annoying subsequently.

Given the docs changes that Philip added in #1043, I think we're safe in changing the type of .timeZone to Temporal.TimeZone, because our docs will clearly state that:

However, most other code will assume that custom time zones act like built-in Temporal.TimeZone objects.
If you want to interoperate with libraries or other code that you didn't write, then you should implement all the other Temporal.TimeZone methods and properties

This seems like a strong enough guarantee that code that follows best practices will quack like a TimeZone. If developers aren't following best practices, then they can always override our TS types to require more strictness. A good way to think about TS types is like lint rules-- because they're customizable by the developer they don't have to be perfect, and corner cases of users not following the docs or doing weird things shouldn't break the DX of everyone else.

[ptomato]

This issue no longer applies to the proposal. Polyfills will have to decide this for themselves.