It seems like some people don't understand the use case for week numbers, at least for businesses. They allow the ability for time series comparisons for a work week. Using the calendar date is hopeless because the 21st day of a month could fall on any day of the week.<p>I want to compare the Monday of the first work week of the year to the Monday of the first work week of last year. That's most helpful when trying to understand sales trends, etc.
That is a surprising amount of complexity, really makes you glad that ISO ironed out all the details, so when I recently told our development team composed of Swiss, German, Portuguese and Danish people that we would be going live in week 4 (of 2020), everyone understood just fine.<p>I still find it strange that some countries have not adopted week numbers. Sure, you can say something like "the week of December 21st", but simply saying "week 52" is so much easier, and if you, like many software teams do, work in two week sprints, it saves you from a lot of date math.
ISO week numbers are used a lot in some industries here in Sweden. For example education, so everyone here has encountered them at some point in their lives.
Note that `strftime` (and implementations dependent on it - hello Python!) do <i>not</i> implement ISO week numbers. In `strftime` all days preceding the first Sunday/Monday (depending which date-code you pass to the function) in a year are classified as "Week 0" as opposed to the ISO definition. This means that `strftime` week numbers are generally 1 less than the ISO week number.<p>As serendipity would have it I was delving into this issue just this morning... :O
As mentioned elsewhere, Intel uses "Work Weeks" for everything. It might be great for manufacturing where a wafer takes a specific number of days to make it through the fab, but it inflicts horrible pain on the folks who have to deal with it <i>and</i> the outside world. My doctor, for instance, stubbornly pretends to not understand when I ask for an appointment in WW04!<p>December 30th, 2019 is WW01.1 2020 in this calendar. I bet no human in the world knows their WW 2020 birthday.
The real fun with this one is when you use (assuming strftime) %G when you really meant %Y, and so your dates flip out for a few days right around this time of year. What's more, it's a different pattern every year.<p>Twitter, Apple's iOS calendar alarms, the list goes on.
There are also non-ISO variations such as the 445 calendar:<p><a href="https://en.wikipedia.org/wiki/4%E2%80%934%E2%80%935_calendar" rel="nofollow">https://en.wikipedia.org/wiki/4%E2%80%934%E2%80%935_calendar</a>
Dates are really hard (I mean data type ones, but ymmv). Numerous libraries claim to be “standard” or to cover almost all date/time functions, but rarely do so. Some libraries allow a developer to see a date as a primitive value/breakdown, which may lead to hard to debug issues (unix + 86400, etc). Leap years, leap seconds, DST, “leapy” UTC/GMT+ days, accidental month overflow, shift date vs duration mismatch, etc. If you’re a developer and never scratched this topic, be aware.
Dates and times are really screwed up as far as programming goes and there is not much to do about it since that’s the way the earth rotates around the sun and itself. Maybe we should start looking for a planet that has a precise 100 day year without leap years? That year can then be split into 10 weeks. Programming on this planet would be much easier.
I wrote a stupid little calendar program that uses ISO weeks <a href="https://github.com/tingletech/tingcal" rel="nofollow">https://github.com/tingletech/tingcal</a>
in Denmark it is quite normal to communicate by week numbers rather than dates. works well, some people are not used to it if they didn't grow up with it.