Skip to content

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

Conversation

brageh01
Copy link
Contributor

@brageh01 brageh01 commented Mar 4, 2025

Changes made to:

  • PlainDate
  • PlainYearMonth
  • ZonedDateTime
  • PlainDateTime
  • PlainMonthDay

Merged calendar-number.js and calendar-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 to calendar-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 and argument-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 a invalid-iso-string.js?

Is the "merge-and-extract» also relevant for relativeto-propertybag-calendar-number.js and relativeto-propertybag-calendar-wrong-type.js?

@brageh01 brageh01 requested a review from a team as a code owner March 4, 2025 11:32
@brageh01 brageh01 changed the title Reorganize calendar and wrong-type tests Temporal: Reorganize calendar and wrong-type tests Mar 5, 2025
@sffc
Copy link
Contributor

sffc commented Mar 5, 2025

Issue: #3873

@sffc
Copy link
Contributor

sffc commented Mar 5, 2025

About the questions: my sense is that the propertybag tests are probably also in scope to be refactored here in a similar way.

@brageh01 brageh01 marked this pull request as draft March 11, 2025 14:07
Copy link
Contributor

@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.

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";
Copy link
Contributor

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.)

@ptomato
Copy link
Contributor

ptomato commented Mar 12, 2025

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.

@ptomato
Copy link
Contributor

ptomato commented Apr 11, 2025

@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.

@brageh01 brageh01 force-pushed the merge-and-extract-calendar-number-and-wrong-type-tests branch from 6eaedd0 to 6e4e4b9 Compare April 16, 2025 11:44
@brageh01 brageh01 force-pushed the merge-and-extract-calendar-number-and-wrong-type-tests branch from 6aa3d10 to 3b39021 Compare April 16, 2025 12:08
@brageh01 brageh01 force-pushed the merge-and-extract-calendar-number-and-wrong-type-tests branch from eb1a1da to 2d6491a Compare April 16, 2025 12:26
@brageh01 brageh01 marked this pull request as ready for review April 17, 2025 13:36
Copy link
Contributor

@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.

@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.
Copy link
Contributor

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.

Copy link
Contributor Author

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"],
Copy link
Contributor

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.)

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

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.
Copy link
Contributor

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.

Copy link
Contributor

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"],
Copy link
Contributor

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.

@brageh01 brageh01 requested a review from ptomato April 23, 2025 19:55
Copy link
Contributor

@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.

Thank you for all the work on this pull request! This looks all correct.

@ptomato ptomato merged commit 443f0d2 into tc39:main Apr 23, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants