Temporal.TimeZone docs #316
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Unscientifically adopting Wikipedia's preference of "time zone" above "time zone" and "time-zone".
Codecov Report
@@ Coverage Diff @@
## main #316 +/- ##
==========================================
+ Coverage 78.26% 79.69% +1.42%
==========================================
Files 17 17
Lines 3410 3413 +3
Branches 338 353 +15
==========================================
+ Hits 2669 2720 +51
+ Misses 725 677 -48
Partials 16 16
Continue to review full report at Codecov.
|
gibson042
reviewed
Jan 16, 2020
ryzokuken
approved these changes
Jan 20, 2020
| ## new Temporal.TimeZone(timeZone: string) : Temporal.TimeZone | ||
| Since `Temporal.Absolute` and `Temporal.DateTime` do not contain any time zone information, a `Temporal.TimeZone` object is required to convert between the two. | ||
|
|
||
| Finally, the `Temporal.TimeZone` object itself provides access to a list of the time zones in the IANA time zone database. |
There was a problem hiding this comment.
@pipobscure is this in the spec, or is it just a helper functionality in the polyfill?
There was a problem hiding this comment.
It's a stub in the spec (https://tc39.es/proposal-temporal/#sec-temporal.timezone.prototype-@@iterator) but it does look like it's intentionally there. It was also mentioned elsewhere in the stub documentation before I expanded it.
There was a problem hiding this comment.
Does anyone know the motivation for this feature? @pipobscure
This was referenced Jan 20, 2020
Incorrect key name in the return value of ES.BalanceTime was causing durations over 1 day to be cropped with disambiguation = 'balance'.
This used ES.GetTimeZoneOffsetMilliseconds instead of nanoseconds, presumably an old method that no longer exists.
DAYMILLIS was actually an hour. The bug with DST was due to the use of DAYMILLIS in GetTimeZoneEpochValue().
We describe in the spec that time zone names are canonicalized, including capitalization and IANA Link Names. Add tests for constructing a TimeZone from these. As well, test the 'name' property which is supposed to be the canonicalized identifier. Note: Different implementations of Intl.DateTimeFormat canonicalize IANA Link Names differently! This example picks one that happens to canonicalize the same in the IANA and CLDR databases. See for background: https://stackoverflow.com/questions/45867761/javascript-intl-api-gives-different-results-in-chrome
The existing code would get negative hours with nonzero minutes wrong, since it would add positive minutes to negative hours.
ryzokuken
approved these changes
Jan 21, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
MDN-style documentation of Temporal.TimeZone, plus minor bug fixes so that the examples work.