ISO week date
en.wikipedia.org
en.wikipedia.org
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.
* 30 December 2019 - 5 January 2020 (2020 W01)
* 4 January 2021 - 10 January 2021 (2021 W01)
- WW02-WW16: Conceptual Development
- WW17: CDR
- WW18-46: Detail Design
- WW46-48: DDR
- WW48-52: Validation/Testing
- WW01-02: Ship to customer
So you could just now know how many weeks it took exactly for each phase: - [14] WW02-WW16: Conceptual Development
- [1] WW17: CDR
- [28] WW18-46: Detail Design
- [2] WW46-48: DDR
- [4] WW48-52: Validation/Testing
- [2] WW01-02: Ship to customerI 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.
And if you’d grown up with it, it would be a lot more natural. Much like you probably know what month you’re in without checking your watch, I have a pretty good idea what week we’re in, and if someone says they can deliver something in week 8, I instinctively know that’s late February without having to check.
So it’s a useful shorthand in many ways.
That’s like saying imperial units are more natural than ISO units because you grew up with them. Of course what you grew up with is more natural to you, it doesn’t say much. The problem is not everyone grew up with it, compared to “the week of Dec 21.”
Not saying week numbers aren’t useful, I’ve used them to label weekly results in datasets, for instance.
I suppose all those calendar software I've seen over the years ain't true scotsmen.
I've pondered on dates and how to divide the year down to how long weeks should be — for way longer than I care to admit.
The thing is, we basically need there characters to map dates (it would be easier with a duodecimal/dozenal system for months, but 1-9,A,B works too).
Using weeks, we could say that e.g. "23-2" is the second day of week 23, from 01-1 to 52-2 (or 52-3 on leap years).
This seems like a good business approach to me.
I'd go one step further and map these to Q's, it's 13 weeks for each (13×4 = 52). Which neatly maps to 12 weeks of work + 1 week transition (debrief, brief) between each Q.
What's interesting is that we count hours, projects, deadlines usually in week units — e.g. most labor regulations speak of weekly work hours, whereas months are sketchy depending where weekends fall, 28-31 days, etc.
So it's easy to think e.g.: we got 3 weeks for this, team of 5, that's 3×5×40 = 600 man-hours.
Finally, considering a 5 workdays week (Mon-Fri), you can easily use .2 increments for days: 24.0 for Monday, 24.2 for Tuesday, 24.4 for Wednesday, 24.6 Thursday and 24.8 Friday of the 24th week. What's the use? Well, between e.g. 24.6 and 28.2 you can quickly do the math and get 4.4 = 4 workweeks + 3 days.
It may seem like nothing but math on dates has always been hard when it doesn't have to be. We shouldn't need Excel or Google to quickly calculate date differences, number of days since/until, etc.
At least this is an additive one - unlike imperial/metric, it isn't a unit replacement. Even if you like "better" measures, you may want to stick with local ones. Little story -
I noodle around with metalwork, and have some machinery. Because I lived in Europe for a bit, I am comfortable with metric, and metric mental math is so much less error prone that when I was choosing machinery, I went metric. That was a mistake.
Everyone I've had in my shop freaks out. All the little rules of thumb and patterns for remembering relations between, say, feed rate to mill spindle speed for a particular alloy go out the window. Reading documentation and how-to texts written in the US puts you right back at doing lots of math in weird bases in your head. And so on.
It is fine, I'm happy with my setup. But there are reasons not to pick the "better" method. And those reasons perpetuate the existence of the other ones.
It might be a mistake in the US, but of course machine shops outside the US are all metric - conversely, operating an imperial machine shop might be quite annoying outside the US.
> It is fine, I'm happy with my setup. But there are reasons not to pick the "better" method. And those reasons perpetuate the existence of the other ones.
Interestingly the US industry didn't switch to metric citing "conversion cost" (in the late 19th / early 20th century). Instead we continue to waste billions every year since: keeping double stock, projects failing (see: space), US engineers struggling with the system everyone else uses (and vice versa, though to a lesser extent, since US-made components and machinery are relatively irrelevant in industry) etc.
Imperial fractions also tend to use base-2 numbers as the denominator. I'd be willing to bet that you infrequently saw anything that used thirds or fifths. Most everything would have been halves, quarters, eighths, sixteenths or even thirtyseconds of something.
This isn't in the past - it is an ongoing argument that literally anyone who spends any degree of time in a machine shop gets roped in to. Every machine purchase is a vote on the ongoing argument.
Which is why I explicitly called it out - because of a collective action problem in the US, we can't make a simple, obvious efficiency change (which would indeed cause comparatively brief pain for large ongoing payoffs)[1]. It was a mistake for me to switch for the reasons specified. The interesting part is that correct micro-scale choices create a macro-scale problem.
Seems to be an ongoing theme of the past couple of decades.
[1] If you're not familiar with this, curious why a simple standards issue is well and truly unsolvable, and feeling masochistic you can search Youtube to catch what passes for mainstream political talking heads here making it about "heritage" and how the metric system is part of a UN plot.
At least with the metric system there's no ambiguity, and it's base10 so easier to calculate, and the orders of magnitude make sense. And they also translate; a litre of water is functionally equivalent to a kilogram in weight.
Schools of course find planning the year in weeks very convenient. This bleeds over into holiday planning at workplaces.
Oh? Google calendar and other software I use has them by default.
... What else could I have meant?
That's only if you count Sunday as the last day of a week, instead of it being the first day of the following week.
Not quite: the paywalled standard itself contains bits like "dot or comma" for fractional part separators, which are then interpreted differently. Some software would use a dot (for printing and/or parsing), some would use comma, some would depend on a locale. It also allows to omit time zone (making the time unclear) and is generally quite complex, with implementations being incomplete (or having subtle differences) sometimes. Of course it's better than the zoo of formats, but RFC 3339 (ISO 8601's profile) is considerably better for interoperability, eliminating ambiguities and many options.
EDIT: you are all lying, if christmas movies have taught me anything it is snowing everywhere in the world in december.
Tooling support is generally required to know what specific dates holidays are on as well, and we manage.
It’s not a replacement for dates, but a useful shorthand used when dealing with weeks.
I don’t need to know what exact dates week 27 is when reasoning about it, for most purposes, I can just do simple math to calculate how many weeks it is away.
Week 27 requires some compute to place it somewhere in the year.
If you have a shared context, these kinds of things don’t matter as much. Things get hairy when you don’t, and worse when you think you do, but don’t :)
Used to have an .ics laying around for that purpose.
For those in English locales, Outlook has an option to enable week numbers in calendar views, and mobile calendar apps have this option too (at least the ones I've used).
Which would translate to Wednesday January 8th year 2020
It is useful for deadlines because you always now how many weeks it is left.
Aside from this though, I could never quite get the hang of week numbers and always just found them more confusing than using dates. When my friends say they're going on their summer holidays in weeks 30-32 or whatever it may be, I never know what that means. Is it July? June? August even? I have no idea, and I always have to ask for dates anyway, or look at a calendar, because I can't figure it out in my head.
As serendipity would have it I was delving into this issue just this morning... :O
“%G-W%V-%u”
This is in POSIX
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition...
and C99
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
Python’s documentation explicitly says it only describes the C89 formatting codes and that C99 has more features. https://docs.python.org/2.7/library/datetime.html#strftime-s...
December 30th, 2019 is WW01.1 2020 in this calendar. I bet no human in the world knows their WW 2020 birthday.
Twitter, Apple's iOS calendar alarms, the list goes on.
https://en.wikipedia.org/wiki/4%E2%80%934%E2%80%935_calendar