Today is Sunday April 20,2025 Gnome date shows week number as 17 cal -w does the same I ran date +%U (capital U) I get weeknumber as 16, for date +%V I get week number as 16 date +%U should produce week number of 17, or else all the others are wrong. NOTE GNOME is using Sundays as the first day of the week, which makes today's date (April 20) part of week 17. That is the default convention for most applications, e.g cal: Reproducible: Always Actual Results: date +%U produces 16 Expected Results: 17 Additional Information: man date for %U, %V cal -w
I don't see a bug here: $ \cal -w -m April 2025 Mo Tu We Th Fr Sa Su 14 1 2 3 4 5 6 15 7 8 9 10 11 12 13 16 14 15 16 17 18 19 20 17 21 22 23 24 25 26 27 18 28 29 30 $ \cal -w -s April 2025 Su Mo Tu We Th Fr Sa 14 1 2 3 4 5 15 6 7 8 9 10 11 12 16 13 14 15 16 17 18 19 17 20 21 22 23 24 25 26 18 27 28 29 30 $ date --help | grep 'week number' %g last two digits of year of ISO week number (ambiguous; 00-99); see %G %G year of ISO week number; normally useful only with %V %U week number of year, with Sunday as first day of week (00..53) %V ISO week number, with Monday as first day of week (01..53) %W week number of year, with Monday as first day of week (00..53) date(1) documents that its Sunday based week numbers are zero based. So if you want Sunday as first day of week, and 1 based, you need: $ echo $(($(date +%U -d 2025-04-20) + 1)) 17
First of all We have cal -w to show the week number, and it shows week 17, Is cal using the regular rule for week number, that begins on Sunday? YES. Gnome's graphical calendar with week number option selected showing 17 YES. Website: https://www.saturdaygift.com/current-week-number shows week 17, (Review Jan 1, 2025 therein). But date +%U is showing a week number that does not match, even though date +%U, has Sunday as the beginning week. Checking with other individuals (Fedoraforum.org), they see date %+U returning 16, as wrong. Perhaps the date algorithm is right, but the description for +%U is inadequate, ie incomplete. It should include something like. Date +%U uses the first Sunday of the year to begin counting weeks. If the man page is revised to include the preceding line, then confusion/errors will be avoided. I have switched to using ISO +%V as the method. Please reconsider this bug report as a request to add "Date +%U uses the first Sunday of the year to begin counting weeks." and for +%V Date +%V https://en.wikipedia.org/wiki/ISO_week_date#Relation_with_the_Gregorian_calendar I have no qualms about date +%V
The issue I have is the following today, Sunday, May 4,2025 weekdate shown in the gnome date shows week 19. (ISO week 19 starts today) date +%U shows 18 (as documentation shows monday as ISO week) date +%V shows 18 (as Sunday is the first day of the week). So do I have to do a date +1 with %U to get the ISO weekno that starts with Sunday? Again Gnome's date shows weekno as 19 but not date +%V or date +%U
I forgot to mention cal -w shows 19
Hello Leslie! Sorry for a late reply. The options may seem a bit confusing but I agree with Pádraig that date(1) works as documented here. > weekdate shown in the gnome date shows week 19. (ISO week 19 starts today) That is not entirely true, it may show week 19 if you use a locale that starts with Sunday and the tool counts from 1. However, ISO weeks always start on Monday so May 4, 2025 is ISO week 18. >date +%U shows 18 (as documentation shows monday as ISO week) >date +%V shows 18 (as Sunday is the first day of the week). Both values are correct but looks like you have mixed up the descriptions of the %U and %V format sequences. See the examples below: // %U week number of year, with **Sunday** as first day of week **(00..53)** $ date +%U -d 2025-05-04 18 That is correct, when counting from 0 (e.g. Google Calendar shows 19 because it starts from 1). // %V ISO week number, with **Monday** as first day of week **(01..53)** $ date +%V -d 2025-05-04 18 That is correct as well when counting from 1 (and Google Calendar shows 18 as well). Therefore, date(1) behaves as documented. Nevertheless, if you find this confusing, feel free to raise an RFE with coreutils upstream. Note, however, that such suggestion is very likely going to be considered a breaking change and, thus, rejected. Regards, Lukas