Skip to content

[Bug Report][3.7.4] Wrong number week with locale-provider "fr" #20724

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

Closed
SamsGuamejy opened this issue Nov 22, 2024 · 5 comments · Fixed by #21199
Closed

[Bug Report][3.7.4] Wrong number week with locale-provider "fr" #20724

SamsGuamejy opened this issue Nov 22, 2024 · 5 comments · Fixed by #21199
Assignees
Labels
C: VDatePicker T: bug Functionality that does not work as intended/expected
Milestone

Comments

@SamsGuamejy
Copy link

SamsGuamejy commented Nov 22, 2024

Environment

Vuetify Version: 3.7.4
Vue Version: 3.5.13
Browsers: Firefox 128.0, Google Chrome
OS: Windows 10

Steps to reproduce

When I use the v-locale-provider with "fr" around the v-date-picker, the weekNumber for the first week of 2025, the date-picker write the week 53.
The weekNumber will be week 01 for the December 30, 2024 to January 5, 2025.

Expected Behavior

Display the week 01 for the December 30, 2024 to January 5, 2025. ISO 8601 right

Actual Behavior

Display the weekNumber 53 for the December 30, 2024 to January 5, 2025.

Reproduction Link

Original Playground

Playground for v3.8.0

@SamsGuamejy
Copy link
Author

@MatthewAry :Can you tell me if this issue can be definded like a bug?
Thank you.

@SamsGuamejy
Copy link
Author

First week
The ISO 8601 definition for week 01 is the week with the first Thursday of the Gregorian year (i.e., of January) in it. The following definitions based on properties of this week are mutually equivalent, since the ISO week starts with Monday:

It is the first week with a majority (4 or more) of its days in January.
Its first day is the Monday nearest to 1 January.
It has 4 January in it. Hence the earliest possible first week extends from Monday 29 December (previous Gregorian year) to Sunday 4 January, the latest possible first week extends from Monday 4 January to Sunday 10 January.
It has the year's first working day in it, if Saturdays, Sundays and 1 January are not working days.
If 1 January is on a Monday, Tuesday, Wednesday or Thursday, it is in W01. If it is on a Friday, it is part of W53 of the previous year. If it is on a Saturday, it is part of the last week of the previous year which is numbered W52 in a common year and W53 in a leap year. If it is on a Sunday, it is part of W52 of the previous year.

@MatthewAry MatthewAry added T: bug Functionality that does not work as intended/expected C: VDatePicker labels Dec 7, 2024
@github-actions github-actions bot removed the S: triage label Dec 7, 2024
@MatthewAry
Copy link
Contributor

I will mark this a bug and bring this to the attention to other members of the team because I don't know what commitment has been made to sticking to the ISO 8601 spec. I do note that the VDatePicker uses date-io and the native date object in it's logic. I also note that there is explicit support for internationalization by mounting custom date adapters to the root createVuetify method.

@SamsGuamejy
Copy link
Author

Thx @MatthewAry !

@simon-tackstrand
Copy link

simon-tackstrand commented Dec 18, 2024

We have the same issue. This means that all weeks for 2025 currently is off by one week in the date-picker.

It seems to be a bug in the getWeek() implementation as described here #20490 vuetify.

Rather than vuetify using its own implementation the adapters instance week implementation should be used i.e. dayjs('2024-12-30').week() which returns the correct localized week. However, the date-io adapter interface does not seem to have support for week number which is mentioned here #644 date-io

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: VDatePicker T: bug Functionality that does not work as intended/expected
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants