-
Notifications
You must be signed in to change notification settings - Fork 158
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
ISOMonthDayFromFields: Reject leap day in appropriate cases when calendar is specified. #1395
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1395 +/- ##
===========================================
- Coverage 95.37% 48.30% -47.08%
===========================================
Files 19 18 -1
Lines 11154 5010 -6144
Branches 1832 1113 -719
===========================================
- Hits 10638 2420 -8218
- Misses 511 2156 +1645
- Partials 5 434 +429
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
…ndar is specified. ToTemporalMonthDay accepts 'month' without 'monthCode' or 'year' when no calendar has been specified, for users writing calendar-insensitive code. However, when a calendar has been specified, ISOMonthDayFromFields will still accept 2/29/2001 specified via month and year. This change makes ISOMonthDayFromFields reject or constrain 02-29 when month + year are specified, and keeps acceptance of 02-29 when only monthCode + day are specified. See the added test case for some examples.
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.
This looks like a correct implementation of what we had discussed! Unfortunate that I didn't get it right the first time, but good that you noticed we can remove all those unused abstract operations.
Running all the code samples in the docs through a tolerant markdown snippet parser + execution environment revealed many errors. #1395, #1391, #1380, and this patch's one-line fix in plainmonthday.mjs were all bugs revealed by the documentation code samples. Many of the changes in this patch are slight syntactic changes to make the samples testable and more clear.
Running all the code samples in the docs through a tolerant markdown snippet parser + execution environment revealed many errors. #1395, #1391, #1380, and this patch's one-line fix in plainmonthday.mjs were all bugs revealed by the documentation code samples. Many of the changes in this patch are slight syntactic changes to make the samples testable and more clear. Common classes of smaller issues fixed: - Examples did not include seconds in string representations - Examples contained extra zeroes of precision when not requested - Old calling conventions used; arguments needed to be changed - Some options bags are now used in dedicated places rather than alongside other methods
Running all the code samples in the docs through a tolerant markdown snippet parser + execution environment revealed many errors. #1395, #1391, #1380, and this patch's one-line fix in plainmonthday.mjs were all bugs revealed by the documentation code samples. Many of the changes in this patch are slight syntactic changes to make the samples testable and more clear. Common classes of smaller issues fixed: - Examples did not include seconds in string representations - Examples contained extra zeroes of precision when not requested - Old calling conventions used; arguments needed to be changed - Some options bags are now used in dedicated places rather than alongside other methods
Running all the code samples in the docs through a tolerant markdown snippet parser + execution environment revealed many errors. #1395, #1391, #1380, and this patch's one-line fix in plainmonthday.mjs were all bugs revealed by the documentation code samples. Many of the changes in this patch are slight syntactic changes to make the samples testable and more clear. Common classes of smaller issues fixed: - Examples did not include seconds in string representations - Examples contained extra zeroes of precision when not requested - Old calling conventions used; arguments needed to be changed - Some options bags are now used in dedicated places rather than alongside other methods
Running all the code samples in the docs through a tolerant markdown snippet parser + execution environment revealed many errors. #1395, #1391, #1380, and this patch's one-line fix in plainmonthday.mjs were all bugs revealed by the documentation code samples. Many of the changes in this patch are slight syntactic changes to make the samples testable and more clear. Common classes of smaller issues fixed: - Examples did not include seconds in string representations - Examples contained extra zeroes of precision when not requested - Old calling conventions used; arguments needed to be changed - Some options bags are now used in dedicated places rather than alongside other methods
Running all the code samples in the docs through a tolerant markdown snippet parser + execution environment revealed many errors. #1395, #1391, #1380, and this patch's one-line fix in plainmonthday.mjs were all bugs revealed by the documentation code samples. Many of the changes in this patch are slight syntactic changes to make the samples testable and more clear. Common classes of smaller issues fixed: - Examples did not include seconds in string representations - Examples contained extra zeroes of precision when not requested - Old calling conventions used; arguments needed to be changed - Some options bags are now used in dedicated places rather than alongside other methods
ToTemporalMonthDay accepts 'month' without 'monthCode' or 'year' when no calendar has been specified, for users writing calendar-insensitive code. However, when a calendar has been specified, ISOMonthDayFromFields will still accept 2/29/2001 specified via month and year. This change makes ISOMonthDayFromFields reject or constrain 02-29 when month + year are specified, and keeps acceptance of 02-29 when only monthCode + day are specified. See the added test case for some examples.