Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide TypeScript type of ZonedDateTime.prototype.timeZone #205

Open
ptomato opened this issue Jan 2, 2023 · 0 comments
Open

Decide TypeScript type of ZonedDateTime.prototype.timeZone #205

ptomato opened this issue Jan 2, 2023 · 0 comments

Comments

@ptomato
Copy link
Contributor

ptomato commented Jan 2, 2023

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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant