-
Notifications
You must be signed in to change notification settings - Fork 161
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
Year of week-of-year support #1206
Conversation
@mildgravitas this PR will have to wait for #1198 which will bitrot it. Please, wait for that to land and rebase on top |
(CI is failing due to a bug in CI that is fixed on main, feel free to ignore it) |
I'm requested for review on here, and the PR is marked as draft. Are you looking for early feedback @mildgravitas or full review? |
@gregtatum I think Github autorequested review here? Usually when it says "as code owners" it's because GitHub picked reviewers automatically |
5c17d8b
to
85130fd
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
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.
Left some comments, nothing major but would like to re-review based on the responses.
I'd also like @gregtatum to review the discriminant_idx
and its impact on skeleton selection.
#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))] | ||
pub enum Year { | ||
/// The numeric value of the year, such as "2021". | ||
#[cfg_attr(feature = "serde", serde(rename = "numeric"))] |
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.
question
: why are you renaming it here?
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.
For compatibility with existing usage in test fixtures. I can remove the renames & update the latter if preferable.
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.
please do. ICU4X data shouldn't use renames to conform to anything external. And test fixtures should be updated when the values change.
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.
Done
/// The numeric value of the year in "week-of-year", such as "2021". | ||
NumericWeekOf, | ||
/// The two-digit value of the year in "week-of-year", such as "21". | ||
TwoDigitWeekOf, |
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.
issue
: the TwoDigit
and TwoDigitWeekOf
and Numeric
and NumericWeekOf
comments are exactly the same. They don't help understand what's the difference and why we need both.
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.
They're not equivalent but the difference is subtle. I've added examples to make it more salient.
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.
nit
: Thanks, that's helpful, but the reader still has to derive an implicit information about the actual value. Could you extend the comments for NumericWeekOf
and TwoDigitWeekOf
to:
/// The numeric value of the year in "week-of-year", such as "2019" of the "week 01 of 2019" for the
/// week of 2018-12-31 according to the ISO calendar.
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.
Done
"full": "HH:mm:ss", | ||
"long": "HH:mm:ss", | ||
"full": "HH:mm:ss v", | ||
"long": "HH:mm:ss v", |
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.
question
: why are you changing test data JSON files?
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.
Ah, that's a consequence of the discriminant_cmp()
changes to skeleton matching: the changed patterns are 12<->24 hour translations of CLDR's full or long time patterns. The algorithm (from components/datetime/src/pattern/hour_cycle.rs) here is:
- Take the original pattern & swap 12<->24 hour symbols. e.g. 'h:mm:ss a zzzz' -> 'H:mm:ss a zzzz'.
- Turn the pattern into a skeleton. e.g. 'H:mm:ss a zzzz' -> 'Hmsv'.
- Call
skeleton::create_best_pattern_for_fields()
to find a matching pattern.
Previously 'v' & 'z' were considered distinct so create_best_pattern_for_fields()
would settle for a partial match of 'Hmsv' against 'Hms'. Now it finds an exact match.
It's possible to cancel this change by altering discriminant_cmp()
to compare the inner data for TimeZone
, but given that this is arguably more correct I left it in.
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.
Thanks for the fix!
9bb7802
to
ee46ef0
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Rebased onto dc5ff31 |
This looks good to me - with the changes I requested. I'd like @nordzilla or @gregtatum to review the skeleton's changes in particular before we merge this. |
02dd6e0
to
eac812c
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
Rebased onto 0c855b1 |
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.
Looks good to me overall, though @gregtatum is certainly more of an authority on the skeletons and patterns here, so I'd still like to wait for his review.
I had a couple things I'd like to see changed with regard to style.
@mildgravitas - that looks good to me! Can you please move all components to use |
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! thank you!
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, thank you!
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
202f1db
to
1ad2e0b
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
1ad2e0b
to
df57b8e
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
df57b8e
to
a0e798c
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
…ed the calendar year).
…th adjustments for it. To do this I've loosened get_best_available_format_pattern() to match on FieldSymbol enums but not their data. From the function's greater/lesser matching this is apparently what the function tried to do all along. Without this Year::NumericWeekOf wouldn't match as CLDR skeletons use 'y' even for patterns with 'Y' This accessorily improves full & long time_h11_h12/time_h23_h24 patterns: the h11_h12/h23_h24 coercion logic matches adjusted patterns against skeletons & previously 'z' was not matched againts 'v' leading to the time zone being dropped. If we don't care to expose the week-of year variants in components::Bag & don't care about coerced time patterns then only adjust_pattern_field_lengths() need be adjusted.
…:components::Year.
…n of datetime::options::components::Year
…bab case for serialization
…an empty pattern if there are no matches.
a0e798c
to
8ed516a
Compare
Notice: the branch changed across the force-push!
~ Your Friendly Jira-GitHub PR Checker Bot |
@zbraniecki @gregtatum are there any leftover things to do to land this PR? I think we're just missing a final review. |
@mildgravitas btw, we changed how the data is stored, so if you rebase again you probably will want to |
@Manishearth: Thanks for the heads up. Seems like I'm already top-of-tree from yesterday's rebase onto dc414a8. Running testdata-download && testdata produces no diffs so all good for the time being it seems. |
Ah! I was looking at an older force-push-webhook comment which listed |
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's looking good to me! Thanks for addressing my comments.
Going to hit merge since Zibi already gave an "r+ except for minor issues" review above and they seem to have been addressed; I'd rather not let this bitrot again 😄 |
Implements year of year-of-week support for #488 and: