-
Notifications
You must be signed in to change notification settings - Fork 485
Temporal: Reorganize calendar and wrong-type tests #4415
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
Temporal: Reorganize calendar and wrong-type tests #4415
Conversation
Issue: #3873 |
About the questions: my sense is that the |
…ring test into a separate file for relativeto-propertybag
…de; missing newline
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! It looks like this is on the right track. There may be some tests still left to do. For example, there should be relativeto-propertybag-...
tests in Duration/prototype/round/
and Duration/compare/
as well, and I think there are a lot more argument-propertybag-...
tests; there should be some for every API entry point that takes a Temporal object, for example withPlainTime
methods.
Feel free to use a script to automate a first draft of changes if there are a lot of files to do.
To answer your questions:
Are change to be made for the argument-propertybag-calendar-number.js and argument-propertybag-calendar-wrong-type.js files as well?
Yes please.
However, I notice that the argument-propertybag-calendar-iso-string.js actually tests for valid and not invalid ISO strings here. Perhaps create a invalid-iso-string.js?
That sounds correct.
Is the "merge-and-extract» also relevant for relativeto-propertybag-calendar-number.js and relativeto-propertybag-calendar-wrong-type.js?
Yes.
@@ -9,20 +9,23 @@ description: > | |||
features: [BigInt, Symbol, Temporal] | |||
---*/ | |||
|
|||
const timeZone = "UTC"; |
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 see you found a pre-existing error in this test, we forgot the time zone. Thanks!
(Well, technically it's not an error; in step 4.b-c of ToTemporalZonedDateTime the check for a faulty calendar occurs before the check for a missing time zone. So the test was still correct, but it was testing something different than I expected.)
Normally I would suggest that we should make a separate test file to ensure that the "faulty calendar" exception is thrown before the "missing time zone" exception, but in this case I think no further action is needed. We generally don't test that sort of thing anyway currently. (See also #2746 for a draft of how we might test it in the future.)
One more thing I forgot... please take a look at the indentation. We don't generally enforce particular coding style or indentation choices, but there are some files in this draft where the indentation is a mix of 2 and 4 spaces and we should try to avoid that. |
@brageh01 Looks like there's some new stuff on here, thanks! When it's ready for another review, please let me know either on Matrix chat or by clicking the "re-request review" button. |
6eaedd0
to
6e4e4b9
Compare
6aa3d10
to
3b39021
Compare
eb1a1da
to
2d6491a
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.
@brageh01 Thank you for all the work! It looks nearly complete now. Just some minor comments.
// Copyright (C) 2022 Igalia, S.L. All rights reserved. | ||
// Copyright (C) 2025 Igalia, S.L. All rights reserved. |
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.
No need to update copyright years in existing files (unless you're really rewriting a substantial portion of the file.) This comment applies to several 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.
I believe updating the copyright year for this file is correct. Instead of deleting the previous calendar-number.js
I renamed the file to an invalid-iso-string.js
, but it is initially a new file with different functionality.
Looks like I’ve forgotten the «calendar» tag as well. I will fix it.
-19970327, | ||
1234567890, | ||
const invalidStrings = [ | ||
["", "empty string"], |
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.
Optional: you could consider adding more cases in tests such as this one. For example: strings that are neither ISO strings nor valid calendar identifiers. (If you decide this is out of scope for this PR, that would be fine, but I'd appreciate if you could open a follow up issue on GitHub in that case.)
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 now see that I have not done the merge and extract for round
in the same file location which I will do. In regards of your suggestion of adding more cases in tests "such as this one", do you imply only for the relativeto-propertybag files, or all of the calendar-invalid-iso-string files in general?
I believe it will be more transparent to create a new issue for this, but I can both create a new issue and start a PR after knowing more specificly which files that are relevant.
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 meant for the calendar-invalid-iso-string files in general. Every file where the only test case is ["", "empty string"]
. I agree, it's fine to create a new issue.
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 found an already open issue that covers this topic, I think: #3896
@@ -0,0 +1,21 @@ | |||
// Copyright (C) 2025 Igalia, S.L. All rights reserved. |
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 it's OK to put your own copyright here (yourself, or University of Bergen, whatever applies in this case.) Although the test is similar to one that Igalia wrote, but it's a new test.
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 this test and other files like it, we should now be able to merge primitiveTests
and typeErrorTests
into one array of tests that we can just call typeErrorTests
or wrongTypeTests
or even just tests
, and merge the two loops into one. We no longer have to deal with some entries giving a RangeError.
|
||
const invalidStrings = [ | ||
["", "empty string"], | ||
["1997-12-04[u-ca=iso8601]", "ISO string with calendar annotation"], |
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 this line should not be here. According to my reading of the proposal, it's valid to pass an ISO string to this method.
…eTime As requested in PR comment: tc39#4415 (comment)
…on/prototype round and total
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.
Thank you for all the work on this pull request! This looks all correct.
Changes made to:
Merged
calendar-number.js
andcalendar-wrong-type.js
, due to no special behaviour of number to be tested.Extracted string tests to
calendar-iso-string.js
and renamed the file tocalendar-invalid-iso-string.js
, due to the contents of the file initially testing invalid ISO strings.Questions:
Are change to be made for the
argument-propertybag-calendar-number.js
andargument-propertybag-calendar-wrong-type.js
files as well?However, I notice that the
argument-propertybag-calendar-iso-string.js
actually tests for valid and not invalid ISO strings here. Perhaps create ainvalid-iso-string.js
?Is the "merge-and-extract» also relevant for
relativeto-propertybag-calendar-number.js
andrelativeto-propertybag-calendar-wrong-type.js
?