-
Notifications
You must be signed in to change notification settings - Fork 22
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
Fix startOf function for isoWeek #23
Conversation
Fixes _isoWeekday function in order to calculate the right start of week
Uses the ABS of weekday in order that whatever number will be passed, the calculation will be always coherent
This could probably use some tests |
Changes the modulo instance as const instead of var. Adda blank before { for _isoWeekday function
The days diff defined as const instead of var
Well, as you have seen, I'm not so expert on JS therefore I need time to understand how to do it. Do you mean to add some tests into https://github.com/chartjs/chartjs-adapter-luxon/blob/master/test/specs/luxon-adapter.spec.js? |
Yeah, add a test in that file and then run I was thinking it'd be good to check each day of the week or at least the ones on the border like Sunday and Monday Let me know if you have any other questions |
It looks to me like |
It doesn't work with your suggestion. If you try with 2020-08-01 (Saturday, 1st Aug), the startOf (passing 7, Sunday) should be Jul 26th but instead the result is Aug 2nd. |
Thank you @benmccann Let me take time but I'm gonna do. My doubt is to install something that I have to use only for this use case.... I don't usually use NodeJS and then npm as well. |
Why is that? It doesn't sound right to me. The start of the week is July 27 (Monday). The 7th day of that week is Aug 2 (Sunday) I just tried |
Maybe I'm wrong to understand what |
@benmccann I have created the unit test, checking all days of August and it works with gulp (not committed yet). it('should startOf correctly using isoWeek preset', function() {
const adapter = new _adapters._date();
const dayOfWeekNames = ['Mon', 'Tue', 'Wed', 'Thu', 'Fri', 'Sat', 'Sun'];
for (let dayOfWeek=0; dayOfWeek<dayOfWeekNames.length; dayOfWeek++) {
for (let dayOfMonth=1; dayOfMonth<=31; dayOfMonth++){
const dt = DateTime.local(2020, 8, dayOfMonth, 8, 30);
const startOf = adapter.startOf(dt.valueOf(), 'isoWeek', dayOfWeek+1);
expect(adapter.format(startOf, 'ccc')).toEqual(dayOfWeekNames[dayOfWeek]);
}
}
}); |
Ah, no, |
I'm completely lost, sorry. Let me try to do an example: startOf ("2020-08-01", "isoWeek", 7): the result should be 2020-08-02 because I'm requesting the last day of the week of that date. Is it right? Edit: if it is so, |
Date-fns adapter (and I think moment too) take the parameter as the start day of week. |
The moment adapter does And |
@benmccann if you use If I understood correctly, startOf ("2020-08-01", "isoWeek", 7): the result should be 2020-08-02 because I'm requesting the 7th day of the week of that date. I'm just wondering why the method is called |
Its date-fns adapter is doing a different thing then. |
@kurkle you're right. DateFns is doing what I thought, returns the first of the week and you can set the starting point. Now I don't know anymore which is right and which is not. If the startOf iso week should return the first day of the week (selected by the time's argument) based on weekday passed as argument, the Luxon (and maybe Moment) should be changed.
Instead, If the startOf iso week should return the day of the week (selected by the time's argument) based on weekday passed as argument, the Datefns should be changed.
Maybe I see another point of attention. For Datefns, the weekday must be between 0 (Sunday) and 6. For Luxon and Moment the weekday must be between 1 and 7 (Sunday). I don't see any normalization in the adapters. |
Hmm. The docs say that the property is a So I guess the question should be how do we want this to work and then we should update everything to match. Should we target the date-fns adapter's behavior and update the rest to match it? |
@benmccann you have raised an interesting topic that I haven't checked yet. The doc says
that means change the Make sense? |
I might be missing something. But ISO week starts from monday by definition and does not have partial weeks. I'm not sure if there is a week numbering system starting from sunday and having no partial weeks. And if there is, are the rules for first week the same (eg. 4th of jan is always on week 1) US numbering has partial weeks. so Jan 1 is always first day of week, right? But that is the There are couple of other system in the US too, at least for broadcasting and accounting. The accounting one might be the one that
|
@kurkle you're right, and it's always an annoying topic. Nevertheless, due to what the doc is saying clearly, you can start providing Monday or Sunday and maybe the first implementation (we are fixing the missing function on Luxon) could fit the current use case. And then, you can start thinking which use cases could be addressed to improve it. |
@kurkle @benmccann I had a look to CHART.JS code where and how There are 2 calls into https://github.com/chartjs/Chart.js/blob/master/src/scales/scale.time.js const {parser, round, isoWeekday} = options; // <-- here is reading the options and isoWeekDay is BOOLEAN
...
if (round) {
value = round === 'week' && isoWeekday
? scale._adapter.startOf(value, 'isoWeek', isoWeekday) // <-- here isoWeekDay is BOOLEAN, not NUMBER
: scale._adapter.startOf(value, round);
} and const weekday = minor === 'week' ? timeOpts.isoWeekday : false; // <-- here is assigned as BOOELAN
....
// For 'week' unit, handle the first day of week option
if (weekday) {
first = +adapter.startOf(first, 'isoWeek', weekday); // <-- passed as BOOELAN
} In both cases, the weekday argument of Furthermore I'd suggest to change the date adapter doc (in Chart.js) in the code changing the type of argument of If you agree, I can try (taking time, sorry) to submit the issue and then the PR on all involved projects, starting from this one (luxon-adapter). Let me know. |
@benmccann @kurkle updated the PR accordingly with the previous post. I have also added test cases for |
src/index.js
Outdated
@@ -23,7 +23,7 @@ Chart._adapters._date.override({ | |||
_create: function(time) { | |||
return DateTime.fromMillis(time, this.options); | |||
}, | |||
|
|||
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.
should remove this newly added whitespace
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
Yeah, you're right that it's treating |
@benmccann Just to complete the analysis. The moment adapter is working if you use The date-fns adapter is working well because the weekday start from 0 (Sunday and it's also the numeric representation of |
FYI I have already changed and tested the other adapters on my forks, as well, therefore I can push whenever you want. |
I'd prefer the 0-6 or 1-7, because I have an wip app supporting saturday as the first day of week (and using chart.js with date-fns) |
Ok, that sounds fine to me. It is more flexible. Any preference on 0-6 or 1-7? I don't really have one. The date-fns one already uses 0-6, so that'd be fewer adapters to update 🙂 And it's also more standard programmer's indexing, so I guess I have some slight preference for it |
Already changed using the week day between 0 (Sunday) and 6 (Saturday). |
@kurkle @benmccann I have created 2 issues into moment and date-fns adapter project and the related PRs with the same logic. |
I'm wondering if the trunc/min/max is a bit excessive? It would actually hide an configuration or programming error. A slight performance hit maybe too. |
I coded like that to avoid mistakes on date calculation. |
* Update rollup and add ESM output (#17) Update rollup and add ESM output * Update README with latest version (#15) * Remove bower (#19) * Remove use of helpers for v3 compatibility (#20) * Fix startOf function for isoWeek (#23) Fix startOf function for isoWeek * Bump version to 0.2.2 (#21) Co-authored-by: Colin Griffin <[email protected]> Co-authored-by: stockiNail <[email protected]>
Fix startOf function for isoWeek
Fixes #22