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
There are several open issues related to custom time zones. I think it might be easier to discuss all of these issues together because the answer to one might influence our decision on the others. LMK if I missed any.
There are several open issues related to custom time zones. I think it might be easier to discuss all of these issues together because the answer to one might influence our decision on the others. LMK if I missed any.
ZonedDateTime.prototype.timeZone
be a TimeZone? Or can it be a TimeZoneProtocol with some TimeZone properties and methods not implemented? If the latter, how to address the usability concerns outlined in Conflict between docs and polyfill for cloning using TimeZone.from and Calendar.from #810 (comment)?Does
TimeZone.from
always clone the input, or are there cases where it will return the same input back to the user? If "same input back" then is this an SES concern? Conflict between docs and polyfill for cloning using TimeZone.from and Calendar.from #810Can custom time zones be plain objects or must they inherit from TimeZone? If "must inherit" then how do we handle cross-realm cases noted by @gibson042 (FYI - @littledan had questions about this in How to handle this code? Temporal.TimeZone.from({timeZone: 'Asia/Tokyo'}) #925 (comment))
How do the answers above vary (if at all) for custom calendars vs. custom time zones?
The text was updated successfully, but these errors were encountered: