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.
Given the docs changes that Philip added in https://github.com/tc39/proposal-temporal/pull/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.
Moved from https://github.com/tc39/proposal-temporal/issues/1041, follow-up from https://github.com/tc39/proposal-temporal/issues/1037 and https://github.com/tc39/proposal-temporal/issues/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.
(Note, after https://github.com/tc39/proposal-temporal/issues/1808 the ZonedDateTime.prototype.timeZone property will be replaced by a getTimeZone method. The question remains the same.)
From the original issue's comments: