ISO week date(en.wikipedia.org)
en.wikipedia.org
ISO week date
https://en.wikipedia.org/wiki/ISO_week_date
90 comments
I find week numbers very cumbersome to use. Most calendars don't have them by default and most everyday interactions around dates don't involve them. As a result it's a burdensome and unroutined lookup in some arbitrary calendar somewhere just to figure out ballpark distances from current moment. I much prefer date ranges.
It is a communicative convention. If you're the only person following a convention, it isn't.
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.
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.
> I went metric. That was a mistake.
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.
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.
I live in Canada, we use metric, I had to learn imperial when I started at a machine shop. The machines all worked to .0001 inches and we measured our pieces to 1/16" accuracy. Personally, despite using metric all my life and using it for almost everything else i've done. Using imperial and fractions of inches for that kind of work was more intuitive for me and a lot easier to figure out in my head. I find it a lot easier to mentally add fractions than decimals.
> Using imperial and fractions of inches for that kind of work was more intuitive for me and a lot easier to figure out in my head. I find it a lot easier to mentally add fractions than decimals.
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.
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.
> Interestingly the US industry didn't switch to metric citing "conversion cost"
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.
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.
The worst thing is (ignoring the irony of sticking to 'imperial' measures, as in old British empire measures), US imperial measures are different to imperial measures elsewhere.
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.
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.
Here in Sweden, every calendar includes week numbers. You can enable viewing them in Outlook (I guess both ISO weeks and US style week numbering). Due to some school holidays always falling on the same week (Winter holiday on week 9 in Stockholm, for example), they have impact outside workplaces.
Schools of course find planning the year in weeks very convenient. This bleeds over into holiday planning at workplaces.
Schools of course find planning the year in weeks very convenient. This bleeds over into holiday planning at workplaces.
Most calendars in the US sold for "business" use show week numbers on each Sunday since week numbers are often used by people in payroll and finance. So it's not too hard to get a calendar that shows them and I also find it useful for things like working out 2/3 week sprints into the future.
Depends a lot on your locale. Physical calendars around here always have them, and all decent calendar software has an option to display them.
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.
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.
> And if you’d grown up with it, it would be a lot more natural.
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.
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.
You could argue that the "natural" part with using weeks is that the weekends split up your working days, but there is no effect of januari becoming februari and that weeks thus are a more natural unit for planning at work.
No, it is natural to us because our working rhythm is based on a week. It just seems logical to think in terms of weeks.
I think it's cultural, acquired indeed.
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.
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.
> all decent calendar software has an option to display them
I suppose all those calendar software I've seen over the years ain't true scotsmen.
I suppose all those calendar software I've seen over the years ain't true scotsmen.
First Thursday of January is always in week 1. That is actually the only rule needed.
The rule is simple, but all the work that led up to the formulation of it wasn’t :)
Why Thursday?
Presumably because then you know that the majority of week 1 is in the new year.
Yes exactly.
Week 1 is the first week where the majority of the days in the week are in the new year. If Thursday is in the new year, so is also Friday, Saturday and Sunday and with those four days in the new year, it is always the majority of the week.
> If Thursday is in the new year, so is also Friday, Saturday and Sunday and with those four days in the new year, it is always the majority of the week.
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.
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.
ISO counts Monday as the first day of the week.
On the other hand, when I hear "the week of April 9th" I do not have to think a lot about when this is, around which holidays (I am in France :)), the kind of weather we will have, etc.
Week 27 requires some compute to place it somewhere in the year.
Week 27 requires some compute to place it somewhere in the year.
Does the week of April 9th start on a Monday or a Sunday?
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 :)
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 :)
Week numbers are a staple in many countries calendar systems. In Sweden most school children follow a weekly curriculum for instance. We also mark milestones of pregnancies by week numbers as opposed to trimesters.
In the US weeks are also used for pregnancies. Trimester is more of an informal thing since it’s so imprecise.
> ISO ironed out all the details
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.
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.
That's a bad example. Knowing what week 4 is is easy ("End of January"). What's week 27? Or week 43? Without looking at a calendar I can only roughly guestimate.
Week numbers are easily compared to your present time. If you are in week 19, and you know you have to finish something by week 27, you can easily calculate how many weeks you have until that time.
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.
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.
how am I supposed to know when week 33 is?
You enable week numbers in your computer's calendar.
interesting, this makes me think of Java that requires an IDE to be usable as a developer.
If you weren't used to regular calendars you wouldn't know that "August 10" means "about the middle of winter" either
August 10 is actually the middle of summer oO
EDIT: you are all lying, if christmas movies have taught me anything it is snowing everywhere in the world in december.
EDIT: you are all lying, if christmas movies have taught me anything it is snowing everywhere in the world in december.
Not in the Southern Hemisphere.
Not if you are living south of Tropic of Cancer.
How about for the southern hemisphere?
in the northern hemisphere.
If your locale supports them, then all calendars would contain them. I worked in many EU countries a couple of decades ago and they all had them in their print and work calendars and the software had it as well.
Tooling support is generally required to know what specific dates holidays are on as well, and we manage.
Tooling support is generally required to know what specific dates holidays are on as well, and we manage.
people have been using computers to make sense of the calendar since at least as far back as the Antikythera Mechanism. "you need a computer to figure it out" isn't a valid criticism of a date system, it's a tautology.
[deleted]
If you’re planning at work, it’ll suffice to know that it’s 34 weeks away, more than half a year. If you work two-week sprints, you can easily calculate how many sprints you’ll have until them.
It’s not a replacement for dates, but a useful shorthand used when dealing with weeks.
It’s not a replacement for dates, but a useful shorthand used when dealing with weeks.
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 and the outside world. My doctor, for instance, stubbornly pretends to not understand when I ask for an appointment in WW04!
December 30th, 2019 is WW01.1 2020 in this calendar. I bet no human in the world knows their WW 2020 birthday.
December 30th, 2019 is WW01.1 2020 in this calendar. I bet no human in the world knows their WW 2020 birthday.
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.
[deleted]
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 https://github.com/tingletech/tingcal
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.
[deleted]
betimsl(6)
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.
As a Swede I'd say week numbers are pretty ubiquitous in Sweden, with perhaps the first exposure to using week numbers being primary school. I remember counting down to week 9 (spring break) and, I guess, all the other breaks too.
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.
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.
Week 9 is the only week I know "by heart", for this reason. All other weeks I can only relate to by looking in the calendar.
A common way at Volvo Cars is to write and talk about dates in this way; week two day three, or 20wk02d3 or just 20w02d3.
Which would translate to Wednesday January 8th year 2020
It is useful for deadlines because you always now how many weeks it is left.
Which would translate to Wednesday January 8th year 2020
It is useful for deadlines because you always now how many weeks it is left.
It’s the first thing I (Norwegian) turn on (or miss) in calendar implementations. Most things are based on week number here too.
I'm British, but have been working with Norwegian companies for many years, and while it took a while, week numbers now feel very natural.
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).
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).
Ditto for Denmark.
Used to have an .ics laying around for that purpose.
Used to have an .ics laying around for that purpose.
Could this be the one of the reasons ISO week dating was chosen as the format for Minecraft snapshots?
Note that `strftime` (and implementations dependent on it - hello Python!) do not 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.
As serendipity would have it I was delving into this issue just this morning... :O
As serendipity would have it I was delving into this issue just this morning... :O
Here is how to format an ISO week date with strftime:
“%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...
“%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...
While it's fine and good that ISO has defined week numbers, it has been less than helpful when working with North American firms whose weeks start on Sunday and who expect January 1st to be week 1. I've ended up having to write custom code to handle this in my programs as most generic libraries support ISO and not much else.
Yeah, there is a lot of languages missing iso week support. Probably because it's not used in the US as much. Found this gist for getting using it in Power BI a couple of weeks ago https://gist.github.com/r-k-b/18d898e5eed786c9240e3804b167a5...
Python 3.6+ added this.
There are also non-ISO variations such as the 445 calendar:
https://en.wikipedia.org/wiki/4%E2%80%934%E2%80%935_calendar
https://en.wikipedia.org/wiki/4%E2%80%934%E2%80%935_calendar
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.
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.
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.
Yep, huge companies like Intel use work-weeks for everything. For e.g. planning huge engineering projects was easy:
- WW02-WW16: Conceptual Development
- WW17: CDR
- WW18-46: Detail Design
- WW46-48: DDR
- WW48-52: Validation/Testing
- WW01-02: Ship to customer
- [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 customerThe ISO weeks are also big in automotive, especially on projects that span over a number of years. It automatically aligned most activities to have a duration measured in whole weeks. Sure, you can use fractional weeks, but then it gets really messy really quick.
I appreciate the usefulness of using weeks to measure time. But on a side note: less than 10% of time assigned for validation/testing and at the very end of a project is, in my experience, extremely ambitious.
Lol, please ignore the details, I just quickly wrote it down without thinking to just make a point :) But I agree, its a ridiculous timeline!
I don't think the following first weeks are comparable by many work metrics:
* 30 December 2019 - 5 January 2020 (2020 W01)
* 4 January 2021 - 10 January 2021 (2021 W01)
* 30 December 2019 - 5 January 2020 (2020 W01)
* 4 January 2021 - 10 January 2021 (2021 W01)
I don't disagree with you. Some of the decisions that went into the ISO standard are real headscratchers for those of us who have been using North American week numbers
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.
Twitter, Apple's iOS calendar alarms, the list goes on.
Twitter, Apple's iOS calendar alarms, the list goes on.
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.