Skip to content

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

Merged
merged 9 commits into from
Oct 14, 2024

Conversation

nekevss
Copy link
Member

@nekevss nekevss commented Aug 21, 2024

This PR refactors TemporalFields into CalendarFields. 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 the TemporalFields representation anymore (along with the TimeZone and offset which will probably be living on the PartialZonedDateTime). Furthermore, the partials were now handling the undefined case of the fields, so the calendar specific fields no longer needed to be an Option. 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 the CalendarMethods trait, but I do think it makes the ergonomics around passing Date, DateTime, and, eventually, ZonedDateTime as a fallback convenient.

cc: @sffc

@nekevss nekevss force-pushed the update-fields-to-calendar-fields branch from 490e190 to 955649a Compare August 21, 2024 23:38
Copy link

@ptomato ptomato left a 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.

Comment on lines 88 to 92
/// 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>;
Copy link

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 Options

Comment on lines 308 to 310
pub fn as_month_integer(&self) -> TemporalResult<u8> {
ascii_four_to_integer(self.0)
}
Copy link

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.

@nekevss nekevss marked this pull request as ready for review September 11, 2024 22:09
@nekevss
Copy link
Member Author

nekevss commented Sep 11, 2024

Marking this as ready for review. There still may be a couple fixes needed, but I think I'd prefer to move forward with this for now, and do fixes in the follow up.

Overall, this is only -6 test262 tests vs. the current version. The primary cause is most likely due to the constraining needed around month and day. (e.g., { year: 2021, month: 99999, day: 500 })

I'm currently thinking of two approaches: switch MonthCode to Month, or CalendarFields will need to take the overflow argument and handle the constrain behavior when constructed (not the biggest fan of the latter).

EDIT: This actually needs a little more work I think

@nekevss nekevss marked this pull request as draft September 12, 2024 13:40
@nekevss nekevss marked this pull request as ready for review September 26, 2024 19:09
@nekevss
Copy link
Member Author

nekevss commented Sep 26, 2024

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> {
Copy link
Member

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?

Copy link
Member Author

@nekevss nekevss Sep 29, 2024

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.

Copy link
Member

@jasonwilliams jasonwilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM nice changes

@nekevss nekevss merged commit efa1df0 into main Oct 14, 2024
5 checks passed
@jedel1043 jedel1043 deleted the update-fields-to-calendar-fields branch October 16, 2024 15:42
@nekevss nekevss added the C-api Changes related to the public API label Nov 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-api Changes related to the public API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants