Using: CE/%ICUDateTime%yyyy%/W%ICUDateTime%ww% returns CE/2022/W51 ...which, as it's Dec 12, 2022, the 51 should really be 50. What's going on?
I suspect your system settings are involved -- it returns 50 under default UK settings.
And while it won't make a difference th the result, you don't need to call ICUDateTime twice and can include the prefix in the formatting: %ICUDateTime%'CE/'yyyy'/W'ww% will do what you want (note the single quotes surrounding the extra text pieces).
Yeah, I thought that too and then I ran it on my system (running Monterey) and it returned CE/2022/W51 for Cupertino's time zone. But it got the right week number for the month. Strange.
Those come directly from the system API, so they are definitively correct as far as Apple and ICU is concerned and not something Keyboard Maestro has control over.
https://www.unicode.org/reports/tr35/tr35-dates.html#Date_Patterns_Week_Of_Year
Values calculated for the Week of Year field range from 1 to 53 for the Gregorian calendar (they may have different ranges for other calendars). Week 1 for a year is the first week that contains at least the specified minimum number of days from that year. Weeks between week 1 of one year and week 1 of the following year are numbered sequentially from 2 to 52 or 53 (if needed). For example, January 1, 1998 was a Thursday. If the first day of the week is MONDAY and the minimum days in a week is 4 (these are the values reflecting ISO 8601 and many national standards), then week 1 of 1998 starts on December 29, 1997, and ends on January 4, 1998. However, if the first day of the week is SUNDAY, then week 1 of 1998 starts on January 4, 1998, and ends on January 10, 1998. The first three days of 1998 are then part of week 53 of 1997.
Week 1 for 2022 started on Dec 27, 2021.
Week 2 for 2022 started on Jan 3.
Week 50 for 2022 started on Dec 5.
Week 51 for 2022 started on Dec 12.
Keep in mind that dates shown are for local times, and functions like TIME return unixtime, so be careful to use a time in the middle of the day (12,0,0) for such functions to avoid timezones shifting the displayed date to a different day.
Similarly, folks on the forum, answering in real time, may have different results for the day of the month/week of the year if they are on different sides of midnight.
1 Like
It isn't just time zone, it's also country settings -- e.g. in China and Australia (@peternlewis) this is week 51. In the UK and US it's week 50. See the explanations on those pages for why.
1 Like
I get week 51 here in Dallas, Texas, US as well (system settings all correct).
The Unix date tool gives the correct week (50):
1 Like
How do you define “correct”? Keyboard Maestro uses the ICU Date Time as used by Apple, which is defined as above.
In any event, if that definition does not match the definition that you want for which week of the year you need, then you will have to work it it yourself, which you should be able to do by using the DOW of January 1, and the DOY (using MJD function perhaps).
Yes, well meant to imply with Cupertino that my locale settings were accurate but, as you point out, that may not be the case.
Anyway, I can confirm the same result sas @ccstone. The date tool says it's week 50 and ICU reports 51. And the US page @Nige_S refers to says 50.
I would be interested to know why ICU thinks it should be 51.
I wasn't being critical of Keyboard Maestro. I meant what the OP was looking for.
I also meant what most people expect – what most commercial calendars in the US show – and what very venerable and widely used Unix utilities like the date command show.
date "+Week %U – %a %b %d %T %Y %Z %z"
Result:
Week 50 – Tue Dec 13 11:09:03 2022 CST -0600
⠀⠀
gcal command line utility:
December 2022
Su Mo Tu We Th Fr Sa CW
1 2 3 48
4 5 6 7 8 9 10 49
11 12 13 14 15 16 17 50
18 19 20 21 22 23 24 51
25 26 27 28 29 30 31 52
ISO-8601 Compliant Calendar:
Apple and ICU apparently disagree with "everyone" else, and I find that curious – but perhaps they do have a really good reason. If so I'd be interested in their rationale.
Apple Calendar on macOS 10.14.6 Mojave:
1 Like
Apparently the difference (if not their rationale exactly) is the first day in which 2022 appears vs. the first full week in 2022. And I'm not sure which one I'd prefer.
Wish it were more specific (full week of year vs. weeks in year).
1 Like
Out of curiosity, I tried the following in an Xcode playground:
import Foundation
print("using iso8601 calendar...")
let calISO8601 = Calendar(identifier: .iso8601)
print(calISO8601.firstWeekday) //2 (i.e., Monday)
print(calISO8601.minimumDaysInFirstWeek) //4
print(calISO8601.component(.weekOfYear, from: .now)) //50
print("using Gregorian calendar...")
var calGreg = Calendar(identifier: .gregorian)
print("my default Locale is en_US...")
print(calGreg.firstWeekday) //1 (i.e., Sunday)
print(calGreg.minimumDaysInFirstWeek) //1
print(calGreg.component(.weekOfYear, from: .now)) //51
print("changing Locale to en_GB...")
calGreg.locale = Locale(identifier: "en_GB")
print(calGreg.firstWeekday) //2 (i.e., Monday)
print(calGreg.minimumDaysInFirstWeek) //4
print(calGreg.component(.weekOfYear, from: .now)) //50
These seem to match up with the rules from UTS 35 that Peter quoted above, specifically: "Week 1 for a year is the first week that contains at least the specified minimum number of days from that year."
So for en_US, the minimum number of days in a week is 1, which means W01 of 2022 is the week that contains Sat 01 Jan and 12 Dec falls in W51. But for ISO8601 and en_GB, the minimum is 4, so W01 of 2022 starts on Mon 03 Jan and 12 Dec falls in W50.
1 Like