marticliment / ElevenClock

ElevenClock: Customize Windows 11 taskbar clock
https://www.marticliment.com/elevenclock/
GNU General Public License v3.0
2.31k stars 176 forks source link

[BUG] Incorrect Week-Number calculation in 2024 #1306

Closed asafhas closed 8 months ago

asafhas commented 8 months ago

Please confirm these before moving forward

Describe your issue

Starting from 1-Jan-2024 the Week-Number calculation for Sunday-base weeks is wrong. Example:

Steps to reproduce the issue

No response

ElevenClock Log

🟢 Using cached lang file
🟡 Using bundled lang file (forced=True)
It took 0.003030061721801758 to load all language files
---------------------------------------------------------------------------------------------------

   ElevenClock's 4.3.3 (v4.33) log: Select all the text and hit Ctrl+C to copy it
   All modules loaded successfully and sys.stdout patched correctly, starting main script
   Translator function set language to "en"

---------------------------------------------------------------------------------------------------

 Log legend:
 🔵: Verbose
 🟢: Information
 🟡: Warning
 🟠: Handled unexpected exception
 🔴: Unhandled unexpected exception
 🟣: Handled expected exception

🔵 Initializing clock 0...
🔵 Using taskbar background color
🟢 Regular sized taskbar
🟢 Clock on the bottom
🟢 Clock on the right
🔵 Clock geometry: PySide6.QtCore.QRect(1720, 1154, 200, 46)
🔵 Full screen rect:  (0, 0, 1920, 1200)
🔵 Using automatic font color
🔵 Font families   : ['Segoe UI Variable Display Semib', 'sans-serif']
🔵 Custom font     : 
🔵 Font size: 9.0
🟡 Desktop button enabled
🟡 Custom loaded date time format (clock 0): WW{%U+1} %H:%M\n%x
🟢 Loaded clocks in 0.7490260601043701
🔵 Show/hide loop started with parameters: HideonFS:False, NotHideOnTB:False, DisableNotifications:True
🔵 Restart loop: 1
🟡 restartClocks function has not been defined yet!
🟡 restartClocks function has not been defined yet!
🟡 restartClocks function has not been defined yet!
🟡 restartClocks function has not been defined yet!
🔵 Starting update check
🔵 Low cpu mode is set to False. DisableNotifications is set to False
🔵 Initializing clock 0...
🔵 Using taskbar background color
🟢 Regular sized taskbar
🟢 Clock on the bottom
🟢 Clock on the right
🔵 Clock geometry: PySide6.QtCore.QRect(1720, 1154, 200, 46)
🔵 Full screen rect:  (0, 0, 1920, 1200)
🔵 Using automatic font color
🔵 Font families   : ['Segoe UI Variable Display Semib', 'sans-serif']
🔵 Custom font     : 
🔵 Font size: 9.0
🟡 Desktop button enabled
🟡 Custom loaded date time format (clock 0): WW{%U+1} %H:%M\n%x
🔵 Show/hide loop started with parameters: HideonFS:False, NotHideOnTB:False, DisableNotifications:True
🟢 Loaded everything in 3.423731803894043
🔵 Initializing clock 0...
🔵 Using taskbar background color
🟢 Regular sized taskbar
🟢 Clock on the bottom
🟢 Clock on the right
🔵 Clock geometry: PySide6.QtCore.QRect(1720, 1154, 200, 46)
🔵 Full screen rect:  (0, 0, 1920, 1200)
🔵 Using automatic font color
🔵 Font families   : ['Segoe UI Variable Display Semib', 'sans-serif']
🔵 Custom font     : 
🔵 Font size: 9.0
🔵 Restart loop: 2
🟡 Desktop button enabled
🟡 Custom loaded date time format (clock 0): WW{%U+1} %H:%M\n%x
🔵 Show/hide loop started with parameters: HideonFS:False, NotHideOnTB:False, DisableNotifications:True
🔵 Restart loop: 1
🔵 Showing tooltip
🔵 Short date string: HH:mm
🔵 TZ 1 is America/Los_Angeles
🔵 Long date string: dddd, MMMM dd, yyyy
🔵 Copying log to the clipboard...

Relevant information

During 2023 the calculation was correct.

Screenshots and videos

No response

yrjarv commented 8 months ago

Maybe you can get a few answers in #1304 even though the two issues are different?

asafhas commented 8 months ago

I saw it, but it's a different issue. Thanks!

marticliment commented 8 months ago
  • The following formats (mentioned in https://strftime.org/) are not working in the app: "%-U" and "%-W".

Try replacing the - for a hashtag #. Dash is for unix/linux, hashtag is for windows.

P.D I will investigate this issue

asafhas commented 8 months ago

The hashtag is indeed solving the "%-U" issue. Thanks for looking into the main issue as well.

yrjarv commented 8 months ago

Sorry that I am "hijacking" this thread, but to me it seems like the attached image would contain the week numbers as per strftime.org's documentation. Week 0 is before the first Sunday, then comes W1 - which might not be how everyone calculates week numbers but unfortunately how strftime does it. If my assumptions about the issue are correct, that would mean that strftime is working as intended Untitled

asafhas commented 8 months ago

During weekdays (let's put aside Sunday), both %U and %W should give the same value. But they are not. Today, Wednesday 17-Jan-2024, %U shows "02" and %W shows "03". BTW, according to this ISO Week calculator, the correct value is "03": https://myweb.ecu.edu/mccartyr/isowdcal.html

yrjarv commented 8 months ago

If my understanding of the %U tag is correct, it counts from the first Sunday of a year (7th of January counts as the first day of week 1), but ISO (and %W) counts week 1 as the first week with 4 or more days that are all in the same year. So, if the year starts on Monday, %W would count week 1 from the following Sunday while %U should count from the Monday where the year starts. In terms of the ISO Week calculator, it counts the same way as %W - in compliance with ISO standards. According to strftime.org the following applies for %U:

All days in a new year preceding the first Sunday are considered to be in week 0.

Now I might of course be wrong about this, or might just have misinterpreted your issue. But I am pretty sure that it is working as intended.

marticliment commented 8 months ago

BTW, according to this ISO Week calculator, the correct value is "03": https://myweb.ecu.edu/mccartyr/isowdcal.html

The issue here is that there is not one ISO only, Python strftime uses ISO 8601 (which is inherited from C 1989 Standard, and used across many other programming languages, even the strftime linux command uses it) while your website does not report on which ISO is based.

I am afraid ElevenClock (which uses strftime functions) is not reporting an incorrect week day, but rather it provides the one from the C89/ISO-8601, which does not coincide with the format you are used to, and with the unspecified-iso week calculator

asafhas commented 8 months ago

Indeed, it looks like Python lib is printing "02" when using "%U" today. It is still strange that for half of the world (according to this site) we are in Week-02, and for the other half we are in Week-03. But this is not a problem of this application.

For our purpose, what is the correct way to print "03" (and not "3") with a manual adjust of the value {%U+1}?

marticliment commented 8 months ago

I am afraid this is not possible right now, since {%U+-i} parses %U as an integer and then adds/subtracts the i offset, without taking formatting into account. You may want to hard-code a zero until we reach week 10, and then remove this zero.

asafhas commented 8 months ago

I understand. Thank you for the quick response. You can close this issue now.