Week of 2018, "Wi" format seems wrong

[derekhu]

Very good timing tool!

Report one issue for the week number of the first week in 2018

Advanced format:

HH:nn:ss 第Wi\nyyyy/mm/dd ddd

Shown as below, 52 is wrong:

Week of Year
Wi = ISO 8601 numeric Week-of-Year. (Europe)
Wu = U.S. like Week-of-Year – beginning on first day of the year, based on sunday
Ws = numeric Week-of-Year – beginning on first sunday.
Wm = numeric Week-of-Year – beginning on first monday.
Ww = SWN (Simple-Week-Number) numeric Week-of-Year.

---

You can check it by Google calendar ID
"p#weeknum@group.v.calendar.google.com"

[mbfoo]

Same here - ISO 8601 describes calender week 1 as the week with the first thursday of the year, but today (Jan 02 2018) CW 52 is shown.

[White-Tiger]

guess we can all agree that the week got more than 4 days xD because it started at Monday...
well... yeah there seems to be a bug^^ I really thought my implementation was right (checked different dates in the past and future)
Will have a look and post an update before the week is over.

[chku2469]

Happy New Year!
I just wanted to create an issue -- you guys are too fast :)

Maybe related to https://autohotkey.com/board/topic/50890-monthcal-week-numbers-wrong/ ?
Summary:

seems to be an old problem with MS products

• inconsistent settings on different windows derivates for registry key HKEY_CURRENT_USER\Control Panel\International\iFirstWeekOfYear
• for ISO 8601 value 1 should be used.
• AFAIK the value only be changed using regedit, not from ordinary windows GUI.

On the other hand I could not verify any effect of this registry value on the display of T-Clock when using format Wi = ISO 8601 numeric Week-of-Year. (Europe).

Potential solution:

• don't rely on windows API, but use private implementation
• Attached is an implementation in Excel VBA: excel-vba-iso-8601-week-number.txt

[White-Tiger]

don't rely on windows API, but use private implementation

it is T-Clock's (my) implementation^^
https://github.com/White-Tiger/T-Clock/blob/master/src/DLL/format.c#L379
The 6 should have been a 7... IIRC it used to be "7" but I somehow thought it was wrong, so I changed it... I don't know why it seemed to work for so long

[nyarlatothep]

Thanks for your efforts!
Is it possible to bring up a new build with this error fixed, cause i'm not able to do one myself.
Thanks.

[chku2469]

Hi nyarlatothep, thanks for your message.
I'm developing software for several decades now.
Unfortunately not with the tool chain used for TClock and not focussing on C and even less on Windows API.
Maybe I could try.
Unfortunately I cannot promise a date.

[White-Tiger]

well.. I could improve my "development cycle", I know that.. for example enable AppVeyor to provide "nightly" builds (though, I want to switch to GCC builds as the primary favored releases) and push commits before everything else is done... Though I prefer to do things in order :P
I'm not sure if Travis CI can provide nightly binaries though...

Also, sorry that I'm behind my schedule.

[White-Tiger]

Now implemented in v2.4.4
(yeah, yeah... it's not been a week xD sorry about that... yet it wasn't a (full) month either)

[chku2469]

Thanks to @White-Tiger - seems to be fixed!

[White-Tiger]

Too bad you guys couldn't just wait until the year was over...
My previous "try" was actually quite close to be accurate.
Between 1999 and 2035, the only years with wrong results are:
    2001, 2007, 2018, 2024, 2029
It's not that much... 😝