VB.NET DatetimePicker - invalid week number

Question

I have a problem with my datetime picker vbnet extension. When the item moves to the new year (2016), the week number displayed on the left is invalid.

I have a "datetimepicker" which is not the default component, it was downloaded here: http://www.codeproject.com/Articles/17063/ExtendedDateTimePicker-control-with-week-numbers

I do not understand why the calendar goes from 53 to 2, and not from 53 to 1.

Perhaps one of you has the same error. Thank you for your time.

Answer 1

I don't understand why the calendar pass from 53 to 2 and not 53 to 1

It works as expected. The way he counts the weeks, those first 3 days of 2016 are considered the first week of 2016.

Please note that the control does nothing related to the calendar or display. This is simply a change in the display style of the calendar window provided by Windows. The code shown on the CP page is all there is, and basically it just sets a style flag to tell Windows to add week numbers:

 style = style | MCS_WEEKNUMBERS; 

The MSDN entry for it indicates:

Week 1 is defined as the first week, which contains at least four days.

Since January 1-3 is not 4 days, it seems that there is either an error, another calendar is used, or MSDN is out of date.

---

From the comments:

From what i understood, what wrong is "date format". Maybe it not a 8601

No, that's more than that: ISO8601 is a calendar that neither Windows nor NET implements. Wikipedia notes:

The first week of the year is the week that contains the first Thursday of the year (and therefore always contains January 4). Thus, the numbering during the week in Jonah is slightly different from the Gregorian for several days close to January 1.

This is what you see on the calendar.

Alternative

But the ISO8601 week of the year is easy to calculate:

Start with GetISOWeekOfYear() from my answer to a very similar question . You can use this to display the ISO8601 week of the year for a selected date on a label or something next to DTP.

Print the numbers of the first and last week for 2011 to 2021:

 Dim cal As Calendar = CultureInfo.CurrentCulture.DateTimeFormat.Calendar For n As Int32 = 2011 To 2017 '2021 dt = New DateTime(n, 12, 21) Console.WriteLine(" ***** {0} *****", n) For j = 0 To 3 Dim NetWk = cal.GetWeekOfYear(dt, CalendarWeekRule.FirstDay, firstD) Console.WriteLine("Invariant Date: {0} ISO #:{1:00} NET #:{2:00}", dt.ToString("MM/dd/yyyy"), GetISOWeekOfYear(dt), NetWk) dt = dt.AddDays(7) Next Next 

Result for 2015/2016:

***** 2015 *****
Invariant Date: 12/21/2015 ISO #: 52 ​​NET #: 52
Invariant Date: 12/28/2015 ISO #: 53 NET #: 53
Invariant Date: 04/01/2016 ISO #: 01 NET #: 02
Invariant Date: 11/01/2016 ISO #: 02 NET #: 03
***** 2016 *****
Invariant Date: 12/21/2016 ISO #: 51 NET #: 52
Invariant Date: 12/28/2016 ISO #: 52 ​​NET #: 53
Invariant Date: 04/01/2017 ISO #: 01 NET #: 01
Invariant Date: 11/11/2017 ISO #: 02 NET #: 02

If you do not want to write your own control from scratch or to license, which can be configured for another calendar ( and has a definition for ISO8601), this may be the best thing you can do.

Bottom line: Week number is not incorrect. It uses a different calendar than you expect / want.

---

Literature:

• Get or Convert NET GetWeekOfYear () to ISO Week
• MSDN: Calendar Calendar Places
• DateTimePicker in the reference source

Answer 2

The control is working fine.

When a year changes over the last few days of the year, it’s 53 in the week — but it’s not a full week. Similarly, the first few days of the year are in the first week, but the control takes the “first day of the week” system to determine when the second week will begin - so it is possible to have anywhere from 1 to 7 days during the first week of the year.

This means that the image you showed shows week 53 because you are in December and week 2 because the second week of January starts on the fourth.

If you go to January, it will display week 1 for the line starting December 28th.

The bottom line is that the first week in January has only 3 days.

This is the normal and correct behavior of this control.