0

I have two dates:

Monday 26/12/2022 Sunday 01/01/2023

Take this code:

CString strDate = L"2022-12-26 00:00:00";
COleDateTime datMeeting;
datMeeting.ParseDateTime(strDate);
const auto iPublicTalkWeekNumber = _ttoi(datMeeting.Format(L"%W"));

The value of iPublicTalkWeekNumber is 52.

Now use:

CString strDate = L"2023-01-01 00:00:00";
COleDateTime datMeeting;
datMeeting.ParseDateTime(strDate);
const auto iPublicTalkWeekNumber = _ttoi(datMeeting.Format(L"%W"));

The value of iPublicTalkWeekNumber is 0.

Why? The 1st Jan 2023 is a Sunday, which rolls back to the 26th Dec, 2022. Why is it not returning 52?

As a result this is messing the logic of my software. The documents say the %W returns a value 0 - 53, based on the first Monday being week one.

How do I correctly handle this?

Andrew Truckle
  • 17,769
  • 16
  • 66
  • 164
  • I think I might understand it now. If it returns 0, then that is 52 of the previous year. Right? – Andrew Truckle Oct 22 '22 at 16:27
  • 1
    The `%W` specifier is odd (like just about anything else in the `strftime` family). As I read it: The first Monday of a year starts the first week of that year, with a week number of 1. All dates prior to the first Monday of a year have a week number of 0. That may or may not map to week 52 of the previous year. – IInspectable Oct 22 '22 at 16:46
  • @IInspectable so the only safe way to do what I want it to compute the Monday for the week I am actually on and get the week number from that date. This would them match the first date as they are both the same Monday date. – Andrew Truckle Oct 22 '22 at 16:50
  • I don't know what the specific issue is you are trying to solve, but I believe that the week number for any given Monday will never be zero. – IInspectable Oct 22 '22 at 17:22
  • @IInspectable The issue is as described. You take the monday, and the following sunday, and you get the week number. Both should match. They don't for reasons we now understand. mSo I have to roll back from the sunday so that both bests are done with teh same mondey. – Andrew Truckle Oct 22 '22 at 17:29
  • Sounds like the *actual* issue is that you're describing time intervals using a closed interval. A half-open interval is usually easier to manage, not just for times (e.g. `x >= this Monday && x < next Monday`). Also conveniently deals with the issue that calculating the highest time value just before midnight for a `COleDateTime` is surprisingly non-trivial. – IInspectable Oct 22 '22 at 17:36
  • @IInspectable To me, the issue is that `COleDateTime:Format` does not return exactly the same week number when you are close to the year swap over. So, the easiest solution is to prevent the problem. Roll back the second date to the same Monday. This way the two week numbers will always be the same. – Andrew Truckle Oct 22 '22 at 17:50
  • Did you try L"2023-01-01 00:00:01" ? Just to see how it's working ... – Flaviu_ Oct 24 '22 at 14:02
  • @Flaviu_ No, I did not ... – Andrew Truckle Oct 24 '22 at 14:08

1 Answers1

0

This workaround resolves my issue:

COleDateTime datFirstMonday;
COleDateTimeSpan spanDay;

spanDay.SetDateTimeSpan(1, 0, 0, 0);

// Rewind the start / end dates back until we get to the Monday
datFirstMonday = datMeeting;
while (datFirstMonday.GetDayOfWeek() != 2)
    datFirstMonday -= spanDay;

const auto iPublicTalkWeekNumber = _ttoi(datFirstMonday.Format(L"%W"));

The above code is used with the Sunday date (but for users of the software it might be another day). Eitherway, we roll back to the associated Monday for that week. Then, we do the test for week number.

This way, I find the matching week number.

Andrew Truckle
  • 17,769
  • 16
  • 66
  • 164