-
Notifications
You must be signed in to change notification settings - Fork 157
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
Date[Time].from(date.getFields()) forgets the calendar #641
Labels
calendar
Part of the effort for Temporal Calendar API
Milestone
Comments
Option 2 seems best. |
This combined with what we discussed in #640 means that |
ptomato
added a commit
that referenced
this issue
Jun 5, 2020
This adds an 'iso8601' calendar and changes the polyfill code for Temporal.Date, Temporal.DateTime, Temporal.YearMonth, and Temporal.MonthDay so that they gain a CALENDAR slot, and delegate all of their calendar-sensitive operations to the object in the CALENDAR slot. Among the changes made to those types: - Constructors gain a calendar argument of type Temporal.Calendar. - Types gain a 'calendar' property of type Temporal.Calendar. - from() accepts a 'calendar' string or Temporal.Calendar. - Temporal.Date and Temporal.DateTime accept a calendar in with(). - Temporal.MonthDay & Temporal.YearMonth throw on a calendar in with(). - The calendar is returned in getFields() (see #641). - equals() and compare() take the calendar into account (see #625). This includes documentation, but leaves out spec changes and all but the necessary test changes for the time being.
ptomato
added a commit
that referenced
this issue
Jun 5, 2020
This adds an 'iso8601' calendar and changes the polyfill code for Temporal.Date, Temporal.DateTime, Temporal.YearMonth, and Temporal.MonthDay so that they gain a CALENDAR slot, and delegate all of their calendar-sensitive operations to the object in the CALENDAR slot. Among the changes made to those types: - Constructors gain a calendar argument of type Temporal.Calendar. - Types gain a 'calendar' property of type Temporal.Calendar. - from() accepts a 'calendar' string or Temporal.Calendar. - Temporal.Date and Temporal.DateTime accept a calendar in with(). - Temporal.MonthDay & Temporal.YearMonth throw on a calendar in with(). - The calendar is returned in getFields() (see #641). - equals() and compare() take the calendar into account (see #625). This includes documentation, but leaves out spec changes and all but the necessary test changes for the time being.
ptomato
added a commit
that referenced
this issue
Jun 9, 2020
This adds an 'iso8601' calendar and changes the polyfill code for Temporal.Date, Temporal.DateTime, Temporal.YearMonth, and Temporal.MonthDay so that they gain a CALENDAR slot, and delegate all of their calendar-sensitive operations to the object in the CALENDAR slot. Among the changes made to those types: - Constructors gain a calendar argument of type Temporal.Calendar. - Types gain a 'calendar' property of type Temporal.Calendar. - from() accepts a 'calendar' string or Temporal.Calendar. - Temporal.Date and Temporal.DateTime accept a calendar in with(). - Temporal.MonthDay & Temporal.YearMonth throw on a calendar in with(). - The calendar is returned in getFields() (see #641). - equals() and compare() take the calendar into account (see #625). This includes documentation, but leaves out spec changes and all but the necessary test changes for the time being.
ptomato
added a commit
that referenced
this issue
Jun 9, 2020
This adds an 'iso8601' calendar and changes the polyfill code for Temporal.Date, Temporal.DateTime, Temporal.YearMonth, and Temporal.MonthDay so that they gain a CALENDAR slot, and delegate all of their calendar-sensitive operations to the object in the CALENDAR slot. Among the changes made to those types: - Constructors gain a calendar argument of type Temporal.Calendar. - Types gain a 'calendar' property of type Temporal.Calendar. - from() accepts a 'calendar' string or Temporal.Calendar. - Temporal.Date and Temporal.DateTime accept a calendar in with(). - Temporal.MonthDay & Temporal.YearMonth throw on a calendar in with(). - The calendar is returned in getFields() (see #641). - equals() and compare() take the calendar into account (see #625). This includes documentation, but leaves out spec changes and all but the necessary test changes for the time being.
ptomato
added a commit
that referenced
this issue
Jun 10, 2020
This adds an 'iso8601' calendar and changes the polyfill code for Temporal.Date, Temporal.DateTime, Temporal.YearMonth, and Temporal.MonthDay so that they gain a CALENDAR slot, and delegate all of their calendar-sensitive operations to the object in the CALENDAR slot. Among the changes made to those types: - Constructors gain a calendar argument of type Temporal.Calendar. - Types gain a 'calendar' property of type Temporal.Calendar. - from() accepts a 'calendar' string or Temporal.Calendar. - Temporal.Date and Temporal.DateTime accept a calendar in with(). - Temporal.MonthDay & Temporal.YearMonth throw on a calendar in with(). - The calendar is returned in getFields() (see #641). - equals() and compare() take the calendar into account (see #625). This includes documentation, but leaves out spec changes and all but the necessary test changes for the time being.
ptomato
added a commit
that referenced
this issue
Jun 12, 2020
This adds an 'iso8601' calendar and changes the polyfill code for Temporal.Date, Temporal.DateTime, Temporal.YearMonth, and Temporal.MonthDay so that they gain a CALENDAR slot, and delegate all of their calendar-sensitive operations to the object in the CALENDAR slot. Among the changes made to those types: - Constructors gain a calendar argument of type Temporal.Calendar. - Types gain a 'calendar' property of type Temporal.Calendar. - from() accepts a 'calendar' string or Temporal.Calendar. - Temporal.Date and Temporal.DateTime accept a calendar in with(). - Temporal.MonthDay & Temporal.YearMonth throw on a calendar in with(). - The calendar is returned in getFields() (see #641). - equals() and compare() take the calendar into account (see #625). This includes documentation, but leaves out spec changes and all but the necessary test changes for the time being.
Option 2 is now the status quo, feel free to reopen this if anyone feels it needs further discussion or we need to mark it for later feedback review. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Small bug: Given the code
d1
andd2
end up being different.d2
equals some date in Gregorian year 5780. Remedies:.getFields()
..from()
.I have a slight preference for 2, regardless of whether we do 3.
The text was updated successfully, but these errors were encountered: