You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 tc39/proposal-temporal#1808 the ZonedDateTime.prototype.timeZone property will be replaced by a getTimeZone method. The question remains the same.)
From the original issue's comments:
Given the docs changes that Philip added in tc39/proposal-temporal#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.
The text was updated successfully, but these errors were encountered:
Moved from tc39/proposal-temporal#1041, follow-up from tc39/proposal-temporal#1037 and tc39/proposal-temporal#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 tc39/proposal-temporal#1808 the ZonedDateTime.prototype.timeZone property will be replaced by a getTimeZone method. The question remains the same.)
From the original issue's comments:
The text was updated successfully, but these errors were encountered: