-
Notifications
You must be signed in to change notification settings - Fork 20
Refactor TemporalFields
into CalendarFields
#95
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
Conversation
490e190
to
955649a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had a look, mostly I lack context though, so take what I say with a grain of salt. It's cool to see the parallel evolution of CalendarFields
with the new Calendar Fields Records in the spec.
src/components/calendar.rs
Outdated
/// Returns the calendar week of year value. | ||
fn week_of_year(&self) -> TemporalResult<u16>; | ||
|
||
/// Returns the calendar year of week value. | ||
fn year_of_week(&self) -> TemporalResult<i32>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these should be Option
s
src/components/calendar_types.rs
Outdated
pub fn as_month_integer(&self) -> TemporalResult<u8> { | ||
ascii_four_to_integer(self.0) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I'm understanding what the integer is used for, but if it's the ordinal month
number - you can't determine that in lunisolar calendars without knowing the year.
Overall, this is only -6 test262 tests vs. the current version. The primary cause is most likely due to the constraining needed around I'm currently thinking of two approaches: switch EDIT: This actually needs a little more work I think |
This is more or less ready for review. Would rather move forward with this as is and address the broken tests in the future. Below are the diff results of running the current version in Boa vs. this PR in Boa. < Fetching latest test262 commits...
< Test262 switching to commit dde3050bdbfb8f425084077b6293563932d57ebc...
< Reset test262 to commit: dde3050bdbfb8f425084077b6293563932d57ebc...
< HEAD is now at dde3050bdb Fix test regression in asyncHelpers.js (#4197)
8c4
< Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal:
---
> Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/:
1570,1572c1566
< `/home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/from/one-of-era-erayear-undefined.js`: Passed
< `/home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/from/one-of-era-erayear-undefined.js` (strict mode): starting
< `/home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/from/one-of-era-erayear-undefined.js` (strict): Passed
---
> `/home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/from/one-of-era-erayear-undefined.js`: Failed
1724c1718
< Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/from results: total: 56, passed: 42, ignored: 0, failed: 14 , conformance: 75.00%
---
> Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/from results: total: 56, passed: 41, ignored: 0, failed: 15 , conformance: 73.21%
2096,2098c2090
< `/home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/prototype/with/overflow-undefined.js`: Passed
< `/home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/prototype/with/overflow-undefined.js` (strict mode): starting
< `/home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/prototype/with/overflow-undefined.js` (strict): Passed
---
> `/home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/prototype/with/overflow-undefined.js`: Failed
2132c2124
< Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/prototype/with results: total: 18, passed: 15, ignored: 0, failed: 3 , conformance: 83.33%
---
> Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/prototype/with results: total: 18, passed: 14, ignored: 0, failed: 4 , conformance: 77.78%
3438c3430
< Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/prototype results: total: 460, passed: 281, ignored: 0, failed: 179 , conformance: 61.09%
---
> Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate/prototype results: total: 460, passed: 280, ignored: 0, failed: 180 , conformance: 60.87%
3512c3504
< Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate results: total: 573, passed: 370, ignored: 0, failed: 203 , conformance: 64.57%
---
> Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/PlainDate results: total: 573, passed: 368, ignored: 0, failed: 205 , conformance: 64.22%
11590c11582
< Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal results: total: 3855, passed: 1568, ignored: 0, failed: 2287 , conformance: 40.67%
---
> Suite /home/nekevss/Projects/boa/test262/test/built-ins/Temporal/ results: total: 3855, passed: 1566, ignored: 0, failed: 2289 , conformance: 40.62%
11595c11587
< Passed tests: 1568
---
> Passed tests: 1566
11597,11598c11589,11590
< Failed tests: 2287 (0 panics)
< Conformance: 40.67%
---
> Failed tests: 2289 (0 panics)
> Conformance: 40.62%
|
} | ||
|
||
// NOTE: This is a greedy function, should handle differently for all calendars. | ||
pub(crate) fn ascii_four_to_integer(mc: TinyAsciiStr<4>) -> TemporalResult<u8> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It still looks like this could return the wrong value on lunisolar calendars?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah 😕 it's a rather greedy function that I'd like to come back to in the future. It should be isolated to being called from solely ISO functions so it should be fine.
EDIT: I'd like to come back to it in the future as I'm not exactly sure I'm 100% comfortable yet with implementing month
/monthCode
logic for ALL calendars and need to look into it more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM nice changes
This PR refactors
TemporalFields
intoCalendarFields
. I'm leaving it as a draft for now as I want to run plug this into Boa and run some tests beforehand.General Context:
This builds on the work from #89 and #92.
With the partials implemented for the
with
methods. The values that would be provided can now be accounted for. Primarily, the time fields really didn't need to exist in theTemporalFields
representation anymore (along with the TimeZone and offset which will probably be living on thePartialZonedDateTime
). Furthermore, the partials were now handling theundefined
case of the fields, so the calendar specific fields no longer needed to be anOption
. In general, I also just think that this is a better native representation of the fields values in comparison to the previous version.Furthermore, this PR also implements better handling for Era and Month Codes according to the Intl era and monthCode proposal.
There are a couple points where feedback/bike-shedding would definitely be appreciated. I think the method names in
calendar_types.rs
are getting a bit unyielding. I am also a bit worried about introducing theCalendarMethods
trait, but I do think it makes the ergonomics around passingDate
,DateTime
, and, eventually,ZonedDateTime
as a fallback convenient.cc: @sffc