ISO-8601 date format reference not publicly available
twitter.com
twitter.com
That does include the period definition format, which I know will disappoint some people.
You mean the milliseconds? You're correct that YMMV with regards to libraries, but a lot of them handle milliseconds as well.
2007-03-01T13:00:00Z/P1M
For something that occurs on the first of each month.
[1] https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
If you want to record a local timestamp historically (e.g. log that this event of the electric facility happened at this time in the history of the facility, at the location of the facility), you want to say exactly when it happened, in the local time of the place, notwithstanding political/societal changes to the timezone it is attached to.
Does this make sense? Talking about time always makes things confusing.
Maybe it's just historical baggage from not wanting to keep that historical record of time zones around for all eternity?
I dunno. It's a bit weird to me. It's a very indirect (precise) measure of something that doesn't seem like it would have much use over just recording the direct measure (TZ and/or just the UTC timestamp)
The more your learn about datetime the more confusing it gets, I suppose :). I guess it's good to know that it can get very confusing (and therefore to tread carefully) and to temper one's expectations of datetime libraries.
The original ISO has some very niche stuff in it people have no interest in supporting. Whereas 3339 is pretty much just the bread and butter of the format.
In the context of the train departure time, it's easy to work out what is meant by a weekday 00:37 arrival, but if they were divorced from each other for some reason, weekdays at 24:37 would be easier to interpret.
Being awake past midnight brings up a few challenges with calendars. My watch wil count a late (late) night walk against tomorrow, not against today. As a human, I consider "tomorrow" as "after I've gone to sleep", not "after midnight". 00:37 is still very much tonight.
For example, this Pacific Surfliner timetable [PDF] from Amtrack, where one train goes 11:36P -> 12:10A for one leg
https://www.amtrak.com/content/dam/projects/dotcom/english/p...
Here's a bus timetable [PDF] from Canada that goes 23:45 -> 00:00 -> 00:07: https://www.gotransit.com/static_files/gotransit/assets/pdf/...
Looking at my copy of the draft of the 4th edition of ISO 8601, it seems they removed the 24:00 feature so now times have to be between 00:00 and 23:59. A shame, I think.
https://developers.google.com/transit/gtfs/reference#stop_ti...
It creatively abuses the lack of range checking in the format, and stretches the human facility of "knowing what I mean". It does not match a real time, though, because no clock shows this time as a current time.
While neat, it's a hack, a way to bend the notion of time, and as such, it ought to cause problems. Fortunately, airlines never seem to use this hack, and are able to indicate "00:37 next day".
As for a shift that starts friday 24:00, you could argue that the shift is actually a 'Saturday 00:00 shift', but the users didn't see it that way; they are scheduling Friday nights shifts and want an extra person late Friday evening.
Also you're describing seems to be intervals, not datetime format.
edit: further:
This is directly from the RFC this thread is about:
Date and time expressions indicate an instant in time. Description of time periods, or intervals, is not covered here.
Firstly, users tend to write them as 23:59:59 or even 23:59. When used as a query, this can skip a second or even a minute of data.
Secondly, 00:00:00.0000 can match the first moment of tomorrow, which may also be wrong, and happens readily when timestamped data is imported from systems with per-second granularity.
Finally, these forms constrain any internal representation, which cannot now ever evaluate to 23:59:59.99995 lest we suffer the same category of fault. This'd limit a standard library's timestamp object to a precision of 10μs, which is pretty coarse for many timing needs.
The proper form, that is, the ideal mathematical representation, is an interval with a closed left/lower bound and an open right/upper bound. That's written like
[00:00:00.0000, 00:00:00.000+1day) or equivalently
{ t | 00:00:00.0000 <= t < 00:00:00.0000+1day }
Some (sadly not all) programming languages have such a construct available in their standard library.
I think there's a paper by Lamport recommending this form, although I couldn't find it in a quick rummage through the archives.
Date and time expressions indicate an instant in time. Description of time periods, or intervals, is not covered here.
sure, your use case sounds valid. but that doesn't mean it needs to be part of the standard or implemented by everybody else. it's the sort of thing that should be implemented by the people who need it and that nobody else has to think about.
See https://news.ycombinator.com/item?id=26279292 .
This has been misrepresented both in the headline here, and by some commenters both here and on Twitter. The original Twitter post clearly talked about economic value and downloading copies for free, not about hiding things from the public. Notions of economic value and charging the highest price that the market can bear are a very different discussion to not publicly available.
I would much rather like to hear if the value that ISO produces is proportional to what they charge. Also, are the incentives properly aligned by charging a fee?
Well, what if I'm tinkering in my spare time? I think if you want people to use a standard like this, you shouldn't charge for access to said standard.
Or you can, but stuff like this comes up. Seems petty to me. There are lots of people out there that don't have money for this, and I can't think of any positives around that.
Most hobbies cost money? Most sports clubs charge money and its not because they want motivated people to stay away .
> There are lots of people out there that don't have money for this
There are people out there who don't have the money for a PC, this group is far larger than any group that can't pay a hundred for the exact text of the standard. Clearly your anger should be directed at Microsoft, IBM, Apple, Google and GNU for not delivering the Freedom (TM) development environment everyone is owed.
We can point fingers at other companies, or, if enough people agree with me, we can pressure them to be less greedy or we could start a new standard body that works for us.
There's lots of things we can do if it bothers us. Doing nothing, however, isn't interesting to me.
Any company can afford to pay for the ISOs. It's not for hobby (99% of the time).
Yes, real costs such as parts for a home server or model aircraft. Not artificially scarce data that isn't even supposed to be copyrighted anyway.
What about the paperwork and hassle of getting your employer to pay up? Even if the company could easily afford it, this is still a real barrier.
What about students, hobbyists, and FOSS volunteers? Why should they be barred from access to the documents?
> It's almost like complaining that electricity and laptops are not free.
That's completely disanalogous.
The ISO organization occasionally makes standards documents available free of charge, e.g. obsolete versions of the Ada programming language standard. Is that comparable to them handing out free laptops?
> I would much rather like to hear if the value that ISO produces is proportional to what they charge.
It's about the chilling effect, it's not about value for money.
> are the incentives properly aligned by charging a fee?
Of course not. As Tim Sweeney said, The value of standards is in their adoption. [0] When standards bodies are deliberately introducing obstacles to accessing their standards documents, the incentives are clearly not aligned.
A standards body should be incentivized to make the standards as widely adopted as possible. An obvious precondition of this is to make them as widely available as possible, yet ISO's MO is to block access to standards documents until payment is made.
Another problem is when laws reference such standards. It should not be permitted for laws to reference any document which is not in the public domain, but apparently that's not how things work; standard bodies are empowered to paywall part of a nation's laws. [1]
I've contributed some code to ZBar. During my research I needed to read the QR code specification but the latest version was not publicly available. I certainly wasn't going to pay hundreds of dollars for some document just so I could contribute code to an open source project on my free time.
I think I managed to find an older version and studied that instead. I remember the standard didn't even contain the information I wanted to know, only vaguely-worded hints and footnotes. Can you imagine paying for this document only to find out the authors didn't even consider your use case? I found other resources on the internet and managed to cobble together enough understanding to solve my problem.
But let's assume ISO would publish only high-quality standards. Wouldn't those be worth their salt?
While I do understand that paying for any document is an issue for hobbyist, let's be honest. Every hobby has costs. A good hobby gardener probably spends $100 on books alone. So, if the standard is good, and really teaches you something, I would buy it even for a hobby.
P.S. Funny that you contributed to ZBar. Our paths cross again. :)
P.S. Yes, I wrote some code to allow ZBar to decode binary data. The ISO standard contributed to my understanding of QR code encoding modes and text encoding metadata. Are you also a contributor?
In case anyone wants to know more about this stuff, I wrote about my research in a Stack Overflow answer:
It's not that the realtor takes no money for the apartment because you do the administration for standards.
Just take a closer look at the business model of the IETF. The IETF receives about $6 Million this year doing the administration from the ISOC. The ISOC members define what "standards" are becoming standards, or should I say "dictates".
Paying ISO has nothing to do with creating or distributing the standards. The developers of the standards are, in all cases I know of, not paid by ISO.
I agree that there needs to be some money for infrastructure. It shouldn't cost very much for a PDF hosting service for publicly-available PDF.
So, in effect, IETF standards are paid for by the employers of people who participate in the IETF, in terms of giving them time to do so and paying for them to go to the meetings.
There are reasonable conflict-of-interest rules for ISOC staff, who are required to be clear when they are speaking on behalf of ISOC or in a personal capacity. Although ISOC provides additional funding, they do not oversee the IETF standards process. That job is done by the working group chairs and by the IESG (aka the IETF area directors) who are nominated by people who attend IETF meetings.
The value of a standard is that it is universally used. ISO standards are only used by people who can afford to pay for them. The very act of charging for them reduces their value.
The requirement of standards adherence for government contracts can raise interesting questions around paid-for standards, too.
Also, the point of standards isn't "learning". The point is to agree on common definitions. It enables interop, that's it.
It's also ridiculous that de facto laws are behind a paywall (because laws often implicitly or explicitly reference standards).
That'd be true if there was only one. But real-world systems often involve a vast number of standards (de facto and de jure).
> I would much rather like to hear if the value that ISO produces is proportional to what they charge.
ISO does not pay the developers of the standards it controls. It prints paper (which few want) or sends PDFs (which cost nearly nothing to store & send). It also manages votes, which today can be done cheaply. Many of ISO's current required costs are only required because they have to implement a paywall.
Don't get me wrong, I think standards have an important place in the world today. And I'd like to see ISO continue. But its antiquated approach involving charging for standards is impeding, not aiding, the use the standards.
For fair use to apply, you need to critique, parody, or otherwise transform the original material in a way that adds something. If you found 800 like minded people then you'd be facing 800 different lawsuits that you'd probably all lose.
That said, I'm pretty sure I could find 800 people who would critique the typography :-). Each usage would be a page that says, "Look at this random page from a standard (page <xxx> by the way), do those serifs really help anything? How is it even readable with the way they break the text in their paragraphs."
This is correct. Instead of cutting and pasting the ISO text, you can explain what the conclusions and rules are. In doing so, you will have the opportunity to both add value by explaining things better and subtract value by explaining things in a worse way. I think it will turn out to not be so easy to publish an "identical" standard in your own words, but it's worth the effort to disseminate free standards.
(Although Thomas did ask in Google v Oracle if perhaps some more factors should be included, since the statute says the factors "shall include" and is therefore not an exhaustive list).
The percentage of copyrighted content is literally one of the four factors that are used to determine if the use is fair.
So using ISO's own terminology, standards available to the public are "publicly available".
IN ADDITION: I think that's the right terminology. If a standard is not freely available to the public, it is NOT publicly available. When there were only a few standards, and you had to pay for expensive typesetting to get a paper document, the costs made sense.
But in the modern world we need to use a massive number of standards, there is no need for the typesetting (or the paper), and the people who developed the standards are not being paid by ISO's royalties. The standards world is nothing like publishing fiction (where the author is normally paid). All standards should be publicly available.
... then think about it like publishing non-fiction, where the author is normally paid.
:)
Yes, ISO is old-school. But why does it really matter to anyone else whether they charge? The standards that most software folks are concerned about are either replicated elsewhere (like rfc3339), or don't really matter.
They'd have a lot more value if they were publicly available.
It’s an entire industry, of course part of that process is paying to get the specification that you’re already paying for someone to verify you’re abiding by.
The last time I went through an audit the consulting firm that was auditing us only very begrudgingly gave us the requirements for a couple of sections because we kept insisting that we were providing proof that we met them and they kept disagreeing. I still think it was just to shut us up...
As they mention in the tweet, you can possibly get them from the standards body in your country. For my current country (Estonia) they don’t seem to give it out freely, but you can buy the version they approved as the country’s standard for like €20, compared with the €200 for the official ISO version. So there are options...
In your dispute with the consulting firm you were expected to buy your own copy of the standard, they don't have the rights to give you one.
I’m not saying every industry has a cert industry, just like not every industry has a regulating body; just that these are predominant enough in IT and related fields that it shouldn’t be surprising to a lot of people here to realize there are a lot of them.
And of course I get that we were supposed to buy our own copy. We actually had our own copy (when paying $20k for an audit the couple $100 for the spec is insignificant), it was just an anecdote I found funny.
They refused to provide anything about the spec so hard, even though we kept insisting we did meet it... they wouldn’t even tell us which part specifically we didn’t meet because they didn’t want to provide any of the spec to us. I think it took the CTO and I sending heavily highlighted copies of the requirements from the spec to them for them to realize that we had it, it was ok to show us specifically what they didn’t think we met.
* https://evs.ee/en/discounts-when-buying-an-estonian-standard
* https://evs.ee/en/search?query=8601&languages=41&organisatio...
2019 revenue of ISO - figures in ‘000s of CHF (edit 1CHF = 1.08USD) - details from page 63 of https://www.iso.org/files/live/sites/isoorg/files/store/en/P...
21181 Membership fees
12924 *Royalties received from members selling ISO standards*
6592 *Revenue – net sales*
2286 Funding of capacity building projects
273 Funding of ISO strategic projects
(99) Financial revenue (loss)
=====
43157 TOTAL REVENUE
Edit: removed subtotal rows “34105 Revenue from members”, “2559 Funding of ISO projects”
More seriously, they spend almost everything on operations. It doesn't seem that much to me, good employees are very costly.
No, they aren't all taxpayer funded. In some countries they are entirely private organizations. ANSI is a non-profit private company, for example. And the ones that are are taxpayer funded are not necessarily wholly so. The BSI gets grants from the U.K. government, for example, but is far from wholly funded by it.
Standards Australia made just under AUD7 millions in 2017 (for example) from selling copies of standards, via subcontractor publisher SAI. This was just under a quarter of its total revenue for the year. Nearly all that would be gone were ISO to start giving away copies for free, and yet SA would be expected to pay an extra AUD0.1 million in ISO fees at the same time.
* https://www.standards.org.au/about/governance/annual-reviews
So what's your proposal for making up for this lost revenue stream as well as paying higher ISO fees? Across all of those 165 countries.
Or begging for donations. Maybe Wikimedia Foundation would be willing to chip in?
You aren't going to pay $100 per standard to access it. Would you pay $1/year for unlimited access to all ISO standards?
So maybe the government should charge you $0.02 more in taxes for this, plus another $0.98 for 49 other things that you don't care about, and make this a public good.
If you eliminated the paywall, there'd be no reason to run a paywall, which imposes substantial costs. A lot of their costs are for printing paper, but one of the main draws for paper is that they lock down the PDFs with onerous licensing restrictions so the paper is often far more efficient from a legal perspective. If they just posted everything as a PDF on a website, they could hide behind a CDN and much of their operations costs would disappear.
I couldn't find specific numbers for how much that would save. But I suspect the majority of their costs - probably 90% or more - would be eliminated if they eliminated the paywall.
Also sister comment mentions that member organisations make a profit from them too, so the revenue lost is greater and member organisations would lose revenue, not just the ISO.
> A lot of their costs are for printing paper, but one of the main draws for paper is that they lock down the PDFs with onerous licensing restrictions so the paper is often far more efficient from a legal perspective.
The reason to publish paper is primarily because of the paywall. Oasis does not bother, nor does the ietf.
If ISO eliminated billing and stopped publishing paper then I would be unsurprised if most of their costs disappeared.
Though they spoil the plot in the abstract.
Correction: upon further research, this is where 440hz originated. However, it was not the original standard (or where musical notes come from), and I find the history interesting, so I'm going to post it anyway.
Tuning used to be based off of whatever instrument was not easily tunable (the piano or organ), or some other instrument (oboe?) if there was none. For much of musical history tuning was significantly lower than A=440, albeit with a lot more variation; however, it tended to rise[0][1] in order to create a more brilliant-sounding timbre (particularly in larger venues), especially among instrumental pieces. This led to some contention, especially with vocalists who found the increasingly-high notes more and more difficult to sing. There were several efforts to readjust tuning to something more reasonable, but ultimately none of them worked for long. Frequency was actually orignically standardized in Article 282, section 22 of the Treaty of Versailles.[2] This may not make a lot of sense at initial glance, but when thinking about it as how good orchestras sound, it does make some sense as an economic policy
This is where I originally messed up, though. The Treaty of Versailles references something else (which I don't have a link for), but which, per [1], standardizes to... 435hz. But again this crept up, and apparently the US and UK did some shenanigans with interpreting it (the UK changed the temperature to get it to 439hz, I haven't found out precisely what the US did), and there was again some debate. Some people gave up and standardized with the UK to 440hz, some stayed at 435, and eventually the ISO did step in and standardized again on 440.
So we may all be breaking international law by tuning to 440hz.
[0] https://en.wikipedia.org/wiki/Concert_pitch#Pitch_inflation
[1] https://www.youtube.com/watch?v=BzznBt8tVnI
[2] https://en.wikisource.org/wiki/Treaty_of_Versailles/Part_X#A...
https://en.wikipedia.org/wiki/A440_(pitch_standard)#History_...
Unless the spec goes into more restrictive detail, you could tune a piano’s A440 honky tonky (roughly: one string 439.5 Hz, one string 440.5 Hz) and still be ISO-16:1975–compliant.
To me, 432 Hz for A just sounds way better and warmer.
I think there has been a drive slightly downwards since the 60s, mainly because instruments and players have become better. Sure, the Vienna Philharmonic might have started at A=440hz, but ten minutes into the recording it has already at 444. I have tried to do play-along to those recording (when fast-learning an orchestra part), and by the end of the movements I can't get up that far.
In my orchestra (80 musicians, triple winds. In Sweden) we start 442, and usually end slightly above 443 (sometimes higher, depending on heat and repertoire). I recently played a concert in the Swedish radio orchestra, and they are amazingly consistent.
But for many instruments, tuning A slightly down to 432 is feasible.
Perhaps future technology can save us so that orchestral music can be fixed in the mix.
As far as I’m aware, the only difference between the two is something related to the - in the time zone offset... though I’ve also seen plenty of libraries parse 8601 with and without -, so it seems not to be super important.
2021-W07-5
Luxon will happily parse 2021-W07-5T00:00:00Z and tell me that it represents 2021-02-18T16:00:00.000-08:00, so I think it's valid.
I was architecting a true-realtime telemetry pipeline for a AAA videogame studio (later used by a dozen or so franchises for all titles by the publisher). It had a requirement for subsecond client notification of per-user aggregated statistics, including complicated event interactions (such as ensuring the grenade that you threw that killed someone, would only be attributed to you if a prior event hadn't already occured), which resulted in sequentiality guarantees. But with that, we could get rid of windowed event processing (and those inherent latencies), and instead treat them as a true stream of events. Keep in mind we could support up to 400ms one-way latency, so we only had 200ms for processing/routing in the client and in the cloud. I measured client code in μs.
Annnyways. The principal in our org insisted that time not be be transmitted as an epoch. I argued for weeks, but he was insistent... "No magical offsets to arbitrary dates. ISO8601. Do it." He came from and worked most heavily with the web services group. Apparently some point in the past, services had picked the wrong epoch and there was confusion (I still can't understand how that wouldn't be caught right away, there's only a few standard epochs that are quite different in resulting time)? The events in my design were bit-packed using a competing protocol to Protocol Buffers... there's no way I was doubling the payloads just to store a timestamp as a string.
So I read and re-read ISO8601. And it dawned on me: ISO-8601 never specifies the encoding. It specifies the order in which information is conveyed, and if in text, the delimiters to use. One example clue is in the definition of basic format, and the call-out that most of the document leverages plain text to communicate their ideas.
basic format format of a date and time representation or date and time format representation comprising the minimum number of time elements necessary for the accuracy required. The basic format should be avoided in plain text.
I ended up proposing the most terrible hack I've had to live with. It involved bit-packed 64-bit integer that stored: 12 bits for year, 4 bits for month, 5 bits for date, 5 bits for hours, 6 bits for minutes, 6 bits for seconds, and the remaining bits for an integer that stores the sub-second fraction. We lost a few orders of magnitude resolution on that end due to the inefficiencies of the earlier packing, but... it worked. And it was in the right order. And there were no "magic" epochs to dissuade the principal engineer.
Most importantly, it sailed through the review process.
Still makes my skin crawl a decade later. And I secretly suspect you technically have to have a T between date and time to be ISO8601 compliant, it's been a long while since I read the spec. But there you go.
Cross-session reporting (such as calculating DAUs or MAUs) reports on the timestamp from the ingestion service, which is applied at the batch level before a batch of events is placed on the event hub for routing (events are batched and transmitted every 16ms off the client). Typically you can get away with treating everything that happened in the same simulation frame as having happened instantaneously... though we use a monotonically incrementing guaranteed-unique sequence identifier for processing using a high-water-mark (one stream is at-least-once sequentially-guaranteed with retries, while the other stream is lower priority and at-most-once sequentially-guarantied without retries).
No amount of ISO spec will help with client clocks being completely arbitrary. :D The ingestion service clocks are NTP synced to datacenter-hosted atomic clocks, but we still see a few-second skew here and there.
I've even done research into how often they drift backwards in time (but that doesn't really happen, since NTP will just slew the system time by delaying, or adjust the clock massively on startup before the game launches).
See the spec: https://tools.ietf.org/html/rfc3339
NOTE: ISO 8601 defines date and time separated by "T".
Applications using this syntax may choose, for the sake of
readability, to specify a full-date and full-time separated by
(say) a space character.
Happily this particular issue is be easily fixed. Let's make a new spec, subsetting both ISO 8601 and RFC 3339.
I hereby introduce... RFC 3339T, which is exactly like RFC 3339, but you have to use a T instead of a space.
EDIT: joshuaissac spotted another difference.
Also I made a repo so we're official: https://github.com/seagreen/rfc-3339T
I made a GitHub repo for the new spec and credited you (https://github.com/seagreen/rfc-3339T). Let me know if you have more suggestions!
An offset of zero, in addition to having the special
representation "Z", can also be stated numerically as
"+00:00", "+0000", or "+00". However, it is not
permitted to state it numerically with a negative sign,
as "−00:00", "−0000", or "−00"."
Thanks for the correction!
This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar [emphasize is mine]
https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0038_i...
https://www.loc.gov/standards/datetime/iso-tc154-wg5_n0039_i...
Do take note of the caveats on the cover.
(Not suggesting that relying on the free draft is great, just providing a reference for people interested in the actual content of ISO 8601, rather than the principles around this issue. The spec is a good read for people interested in datetime representations.)
And he raises a good point downthread, too:
"So, what's the calculus with something like the ISO C++ standard? You sell 1000 copies at $200 = $200,000 lifetime income. Meanwhile, a lack of understanding of C++ details is kneecapping a hundred billion dollar segment of the technology industry. It's absolute madness."
I suspect volunteers working on floss compilers use the draft, but anyone who can expense it has no reason not to.
As an aside, when I need to explain how something works for C, I quote the standard. When I need to explain how something works for C++, I quote Stroustrup's book. The C++ standard is very precise, but also very math-y. Stroustrup is much more approachable.
This is the best summary of why having to pay for standards is a problem. Let's unpack it carefully.
> volunteers working on floss
An enormous, perhaps the most vital, part of the people working on everyday software stuff.
> anyone who can expense it
Companies and organizations that have money and may or may not have a de facto controlling market share of software that implements a spec
What happens when that company with a controlling market share implements a part of the adopted standard that differs in some apparently insignificant way from from the freely available draft? If that difference turns out to be more significant than it appears, now that company has the only truly spec-compliant implementation, and the rest of the market can't interop because of that difference.
Hello vendor lock-in, my old friend.
CLARIFICATION: I suppose that might have been your point--that not much hindering of understanding is going on among the broad C++ community due to standards (un-)availability.
I'm realizing now that the original question was more about those developers doing work on C++ compilers and such than the broad community. Even so, I guess every heavy contributor and project like GCC, LLVM... have bought their own copy of the standard.
Once you're actually trying to implement the system though, suddenly all of that language becomes really helpful.
I agree with the sentiment that a lack of knowledge is kneecapping C++ development.
However, that lack of knowledge isn’t so much about the details, but the big picture. Forget reading the ISO C++ standard, I think most C++ developers would be better served by reading Scott Meyers “Effective C++” series. Forget about knowing the grimy details of of the standard. I would be happy for them know RAII, and avoid naked ‘delete’ calls.
I have some decent C++ experience, but even I try to avoid areas of the language where you have to be a language lawyer trying to parse if what you are doing is undefined behavior.
Yes, ISO c++ standard is the foundation, but there are a lot more idioms and other knowledge to learn about C++ that is far more important for making good C++ developers.
The target of the ISO standard is not your average developer, but rather the people who write the compilers, standard libraries, and books that bring C++ tools and knowledge to the general developer. For them $200 is nothing compared to the time and effort of those endeavors.
In its laxest definition -- endorsed by ISO itself -- it's just a standard managed by a nonprofit standard organization. In the more common definition it only requires royalty-free use plus the org. Requiring free access is unfortunately an extreme in the spectrum of definitions.
For now Google seems to do the standard-pirating job better, partly because it indexes Baidu's Wenku ;)
StandardsHub.org is occupied by ISO
The most useful knowledge I've acquired about building things on the internet came not from framework/library/API docs, but from RFCs published by the IETF.
Industries that are more reliant on non-free standards are surely worse off because of it.
And beyond that, are there any loopholes to workaround the need to pay for a spec?
I'm guessing from your username which standards you are interested in.
[1] free as in beer
Now, whether that's actually enough to convince the administrators to keep it up and risk the time and expense of a lawsuit is another matter entirely - in practice, anything that rightsholders threaten to sue over is probably banned, regardless of the actual legal status.
To my knowledge, wholesale 'rephrasings' of standards documents have never been undertaken, even where royalty-free access to a document is in relatively high demand, such as with the C standard. StackOverflow ends up being the substitute for the standards document.
As well as being a lot of work, it would open the door to small inaccuracies. A lot of work goes into 'laywering' the exact phrasing of such documents.
No, they have. As a specific example, ETSI TS 102 221 contains enough of ISO/IEC 7816-2, 7816-3, and 7816-4 that one can implement a compatible device.
The problem with "closed" standard is that most people if they have to pay for something they find other way, and assume the standard by reading other sources, Wikipedia, the implementation of some library that is supposed to implement the standard, or the drafts of the standard (like it's done with the C standard, do you assume that every developer of gcc have bought the standard?).
A standard isn't a standard because someone wrote a paper and sold it, a standard is a standard if it's used by people. And it happens that since standards are not freely available people makes things that are close but not really conform to the standard, and these things because the de-facto standard. And you developer you have to support these cases.
Let's say ISO8601, there are a ton of applications that produces dates that are similar to ISO8601 format but not quite like it. And that you must support because they are so common... and then you find piece of codes that tries to interpret a date in various ways trying to compensate for minor standard errors. It's a mess that could have been avoided if the standard document were really open.
The fact that partial documentation is enough to make something work isn’t enough to tell your customer to suck up the loss because it was beyond anyone’s responsibilities.
It's publicly available but is not free. There is nothing to discuss here and this is not newsworthy.
But given your user name, and your other comments, I'm pretty sure you mean something else. You want us to stop discussing it, because you don't like us ripping on your organization. Well, you can stop discussing it any time. The rest of us will discuss it as long as it interests us, as often as enough of us find it interesting.
I think we need to call Stallman on this one. We need Copyleft licenses on our standards to prevent this kind of corporate freeloading.
ISO just sunk in my esteem, silly dinosaurs. I hope they get replaced by something that makes more sense.
No that's not how this works. The ISO one is from the 80s, the IETF one from the 2000s. It's the other way around. The RFC is a profile of the ISO.
> ISO slightly improved the rfc, but it is largely the same.
This is not a true statement.
> ISO has taken the free (as in speech) and is now selling a derivative work.
This is also not a true statement.