-
Notifications
You must be signed in to change notification settings - Fork 152
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
Need to be more specific about "according to ISO-8601" in ToISOWeekOfYear #1641
Comments
The spec includes a grammar that should be followed, which is basically a profile of the ISO-8601 grammar in ecmarkup. |
sure, that work for all the Parse* AOs and great, but how would the ISO-8601 grammar to tell me how to What I am asking is for Temporal to include similar level of text as ISO-8601 grammar from ISO8601 to answer how to implement these 3 AOs I do not believe the grammar can be used to answer that. IF it could, please show me one as example. Thanks |
For example, from the spec itself, I don't think we can easily figure out the answer for the following and justify the value for the expected test, right?
right? |
for example, with the current spec text, it is very hard to review the above two PRs for test262 and reach conclusion that the tests were written correctly. |
Meeting, Sept. 2: We determined that adding a reference to the appropriate section in ISO 8601 should be sufficient. |
Please be specific which PART of ISO 8601 and which section in that standard. I have hard time to locate them. and there are also and there are Part 2 too and there are also previous version and and I assume we are referring to Part 1 of the 2019 version? Is that correc? |
I really think at minimum you need to specify
|
Notice my check in to v8 to implement Reviewer does not feel comfortable to approve my check in for an under specified specification text. |
I read ISO 8601-1 , it does not specified how to convert from "year, month, and day" to week. It only define WHAT is "date's week number" without defining how to calculate it from year, month and day. We need the spec text to define HOW it is calculated here. |
ECMA-262 already has a DayWithinYear equation. We had used some handwavy text in ToISODayOfYear about "the ordinal date in the year according to ISO-8601" but this change uses the logic already present in the spec. See: #1641
ECMA-262 already has a WeekDay equation. We had used some handwavy text in ToISODayOfWeek about "the day of week according to ISO-8601" but this change uses the logic already present in the spec. See: #1641
ECMA-262 already has a DayWithinYear equation. We had used some handwavy text in ToISODayOfYear about "the ordinal date in the year according to ISO-8601" but this change uses the logic already present in the spec. See: #1641
ECMA-262 already has a WeekDay equation. We had used some handwavy text in ToISODayOfWeek about "the day of week according to ISO-8601" but this change uses the logic already present in the spec. See: #1641
@FrankYFTang #2178 should improve the situation for dayOfWeek and dayOfYear. I am still looking for a good reference for weekOfYear. |
ECMA-262 already has a DayWithinYear equation. We had used some handwavy text in ToISODayOfYear about "the ordinal date in the year according to ISO-8601" but this change uses the logic already present in the spec. See: #1641
ECMA-262 already has a WeekDay equation. We had used some handwavy text in ToISODayOfWeek about "the day of week according to ISO-8601" but this change uses the logic already present in the spec. See: #1641
Just FYI, I am very closed to land all of my (non 402 version) of Temporal.Calendar code (the last CL got checked in but reverted last night for a simple issue, I will reland it today) EXCEPT this issue inside ToISOWeekOfYear blacking the review of Temporal.Calendar.prototype.weekOfYear. No need to rush since I still have a lot of other task need to complete the landing of other classes anyway. I will work on the (only support UTC version) of Temporal.TimeZone next. For anyone who like to see the progress, I post the tracking of the landing and all related CLs on https://docs.google.com/document/d/1UmZYIbe1Za4FtT8JvxLHx2yFtHqyuJhrjeo99D_IVk8 |
Here are some reference, but not from ISO8601 |
Note to myself, here is what HTML says about week numbers: https://html.spec.whatwg.org/#weeks |
@pdunkel - are you going to work on better specifying https://tc39.es/proposal-temporal/#sec-temporal-toisoweekofyear ? |
I'm intending to do it, but there are a lot of PRs that I want to review before the July agenda deadline first. If someone else wants to work on it, that would be fine with me. |
I landed most of the non-intl implementation to v8 now except since/until of PlainDateTime and ZoneDateTime (see https://chromium-review.googlesource.com/c/v8/v8/+/3750098 ) and the implementation of this (see https://chromium-review.googlesource.com/c/v8/v8/+/3531567 ) Please raise the priority to be higher. If you think the algorithm I used in https://chromium-review.googlesource.com/c/v8/v8/+/3531567/4/src/objects/js-temporal-objects.cc is reasonable and conforming to ISO8601, we may convert that to spec text. Also how does the polyfill implement this? Can we convert that to the spec text? |
Polyfill currently has the implementation of ToISOWeekOfYear in WeekOfYear: (year, month, day) => {
let doy = ES.DayOfYear(year, month, day);
let dow = ES.DayOfWeek(year, month, day) || 7;
let doj = ES.DayOfWeek(year, 1, 1);
const week = MathFloor((doy - dow + 10) / 7);
if (week < 1) {
if (doj === 5 || (doj === 6 && ES.LeapYear(year - 1))) {
return 53;
} else {
return 52;
}
}
if (week === 53) {
if ((ES.LeapYear(year) ? 366 : 365) - doy < 4 - dow) {
return 1;
}
}
return week;
}, Can we just turn this into algorithm to for the spec text? |
I don't know the provenance of this code, and can't guarantee that it's bug-free, so I'm not sure it's the best basis for a spec algorithm. If possible, I would like to avoid writing our own algorithm in the spec, and refer to one from a reliable source instead. Here's an overview of the research I've done so far, if you'd like to work on this. I think the most comprehensive explanation is given in https://webspace.science.uu.nl/~gent0113/calendar/isocalendar.htm which is basically an algorithm with a 400-year-long lookup table to verify it with. This seems like the most promising source to refer to and/or build a spec algorithm from. I also found https://myweb.ecu.edu/mccartyr/ISOwdALG.txt and https://howardhinnant.github.io/date_algorithms.html and then this Perl module https://metacpan.org/pod/Date::WeekOfYear. Ideally a book or a published peer-reviewed paper would be best, but it's been so long since I searched academia that I'm not sure I even remember where to start. I wonder if it would be acceptable to the editors to refer to the The Mathematics of ISO 8601 page, or maybe one of the sources they refer to. |
Does the spec contain the logic required to convert an ISO DateTime to a timestamp (seconds since epoch)? If yes, then we've already opened the can of works of putting parts of the ISO 8601 arithmetic logic into ECMA-262, and I think we should likely add other pieces of it that Temporal requires, such as the week-of-year math. |
We have MakeDay which does not contain a description of the logic for converting an ISO calendar date to a timestamp, but on the other hand we have DaysInYear which does contain a full description of how to tell whether an ISO year is a leap year. |
I cobbled this together from the ISO spec. So with minor adjustments it’s a good base. Adjustment The value of
|
would an alternative for the day stuff be "get day, plus 1, mod 7"? |
No, because
where the correct value for Monday is 1 unless I misunderstood what you mean |
Closed by #2378. |
Three of the AOs in Temporal has the language "according to ISO-8601"
https://tc39.es/proposal-temporal/#sec-temporal-toisodayofweek
https://tc39.es/proposal-temporal/#sec-temporal-toisodayofyear
https://tc39.es/proposal-temporal/#sec-temporal-toisoweekofyear
Please add link to ISO-8601 or add text to exaplain how that work.
and which revision of ISO-8601 are we talking about?
My understanding is ISO standard are not freely available but need to be purchase. IF we do not explain how does it work in these AO then it is hard to implement it or write test against it. RFC or other standard is much easier to reference to. By looking at these three AOs above, I have no clue how to implement them.
@justingrant @ptomato @Ms2ger @ryzokuken
The text was updated successfully, but these errors were encountered: