[HN Gopher] ISO-8601 date format reference not publicly available
___________________________________________________________________
ISO-8601 date format reference not publicly available
Author : tosh
Score : 288 points
Date : 2021-03-09 16:01 UTC (7 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| remram wrote:
| From yesterday: "ISO obstructs adoption of standards by
| paywalling them" (same Twitter thread)
| https://news.ycombinator.com/item?id=26390040
| tosh wrote:
| thanks for the pointer, I missed the discussion!
| HDMI_Cable wrote:
| I know that the ISO has to make money for their operations, but
| fully locking standards behind paywalls seems so inefficient.
| There are plenty of other business models to choose from besides
| a full lock and key.
| [deleted]
| eyelidlessness wrote:
| The first reply that showed up for me just said "that's dumb",
| and well, yup that about sums it up.
| TeMPOraL wrote:
| Yeah, and that reply is from CEO of Epic Games. I don't know if
| this holds any weight with ISO, but it at least explains why
| this particular Twitter thread complaining about access to
| ISO-8601 standard is hitting HN frontpage.
|
| 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."
| kps wrote:
| For C++ there's no practical problem, since the C++ committee
| chooses to make the I-can't-believe-it's-not-ISO 'final
| draft' public.
| scaladev wrote:
| From what I've heard most compiler developers base their
| work off those final drafts, so you'd be better off using
| them anyway. Might be an old wives' tale though.
| aidenn0 wrote:
| I work at a compilers company and my manager has told us
| to _not_ work off the drafts and to expense the standard
| if we lack a copy.
|
| 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.
| cratermoon wrote:
| > I suspect volunteers working on floss compilers use the
| draft, but anyone who can expense it has no reason not to
|
| 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.
| em500 wrote:
| Similar for ISO 8601:
| https://news.ycombinator.com/item?id=26401497
| felixr wrote:
| Exactly, having https://github.com/cplusplus/draft is
| enough in most cases
| RcouF1uZ4gsC wrote:
| > Meanwhile, a lack of understanding of C++ details is
| kneecapping a hundred billion dollar segment of the
| technology industry. It's absolute madness.
|
| 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.
| lgeorget wrote:
| I don't think you can really understand C++ by reading the
| standard to be honest. If you're such an expert you can read
| the standard in its original form, you're probably already a
| seasoned developer anyway.
| munchbunny wrote:
| Usually when you're reading a standard like that it's
| because you're looking for details from an implementer's
| perspective, not the user's. The specifications have to
| make everything including the obvious details explicit,
| which leads to a lot of verbal abstraction that's
| counterproductive to just learning how to use the thing.
|
| Once you're actually trying to implement the system though,
| suddenly all of that language becomes really helpful.
| sblom wrote:
| I doubt that "learn how to speak C++" is why anyone _does_
| read the standard. The standard is used for things like
| ensuring broad compatibility among compiler
| implementations.
|
| 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.
| numpad0 wrote:
| It's the same situation as research journal contracts.
| Universities, major engineering firms, some federal agencies are
| expected to give input to standards body, and then buy the
| complete print book set for use. That's how almost every
| industrial industries worked, up to the point when software
| engineering started to exist.
| chrismeller wrote:
| Well I knew this, but it shouldn't surprise most of the people
| here either. How many factories, data centers, companies, and
| products have you seen that are ISO-something certified?
|
| 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 EUR20,
| compared with the EUR200 for the official ISO version. So there
| are options...
| rjsw wrote:
| Only a subset of standards have a certification industry around
| them.
|
| 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.
| chrismeller wrote:
| Agreed on both points.
|
| 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.
| thewakalix wrote:
| Why should the cost of certifications fall on people who just
| want to see the standards?
| JdeBP wrote:
| The price list and the fact that (apparently) it will ship
| internationally does make EVS quite interesting.
|
| * https://evs.ee/en/faq-2
|
| * https://evs.ee/en/discounts-when-buying-an-estonian-standard
|
| *
| https://evs.ee/en/search?query=8601&languages=41&organisatio...
| n3uromancer wrote:
| And there's also a 24 hour full pay-per-view option available
| for 2.4 EUR.
| fireeyed wrote:
| The people running ISO and other "commercial standards" are in it
| for the grift. If they make the standards free their gravy train
| runs out.
| coding123 wrote:
| The iso standard is pretty much spec'd out enough on Wikipedia.
| numpad0 wrote:
| No, the point of a standard is it's supposed to be somehow
| comprehensive about something so a thing conformant to it can
| be expected to and guaranteed to work.
|
| 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.
| ak217 wrote:
| Yes, and the point of a standard is also that it should have
| an authoritative, immutable copy for a given version of the
| standard. The Wikipedia article is neither.
| diggernet wrote:
| No, there are many bits of 8601:2019 that are not even
| mentioned on Wikipedia.
| kevinpet wrote:
| Is it? Are you sure? Are we following the ISO standard, or the
| Wikipedia standard?
| chrismeller wrote:
| Not to mention the fact that the Wikipedia article
| technically seems to violate the ISO copyright and could
| disappear at some point...
| ThrustVectoring wrote:
| Facts cannot be copyrighted. Phrasing the description of
| YYYY-MM-DD strings and the like in a different way is
| likely sufficient to be freely available.
|
| 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.
| MaxBarraclough wrote:
| > Facts cannot be copyrighted. Phrasing the description
| of YYYY-MM-DD strings and the like in a different way is
| likely sufficient to be freely available.
|
| 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.
| jfim wrote:
| > 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.
|
| 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.
| MaxBarraclough wrote:
| Interesting, thanks. Do ETSI do this in the name of
| making the ISO standard freely accessible, or is it done
| for some other reason?
| jfim wrote:
| No, from what I understand it's done to standardize a lot
| of telecom stuff across Europe. I think they're somehow
| related to the GSM, but I haven't been in the telecom
| industry in well over a decade so my memory is fuzzy
| there.
| alerighi wrote:
| Probably we are following the Wikipedia standard, since most
| if not all the libraries that everyone uses to parse and
| produce ISO dates were written by people that read Wikipedia
| and not by people that bought the standard.
|
| 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.
| s_dev wrote:
| Is this like having an encryption standard that you have to buy
| to inspect? Is this analogy appropriate?
| hwbehrens wrote:
| It's not an analogy -- ISO/IEC 18033-3 [0] is _literally_ an
| encryption standard that you have to buy to inspect.
|
| [0]: https://www.iso.org/standard/37972.html
| rdpintqogeogsaa wrote:
| There's more. ISO/IEC 29192-1 through 29192-7 are standards
| on lightweight cryptography that you have to buy to inspect.
| Total cost for all of them including the one amendment is CHF
| 812.
| Shank wrote:
| You have to buy the ISO 27001 standard, which is a security
| standard: "ISO/IEC 27001:2013 specifies the requirements for
| establishing, implementing, maintaining and continually
| improving an information security management system within the
| context of the organization. It also includes requirements for
| the assessment and treatment of information security risks
| tailored to the needs of the organization."
| s_dev wrote:
| So is this standard considered 'free' and 'open'?
| chrismeller wrote:
| Absolutely not. None of the ISO standards would meet either
| of those criteria.
| arthur2e5 wrote:
| Nah, the term "open standard" is so vague that is
| probably does.
|
| 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.
| michaeltimo wrote:
| Maybe it's the time to think about an open alternative to ISO
| like OpenISO or something.
| flowerlad wrote:
| I ran into this when I need to write an HTML parser. The W3 spec
| references SGML and the spec for that is not freely [1]
| available: https://www.iso.org/standard/16387.html
|
| [1] free as in beer
| beojan wrote:
| I think you mean SGML. XML is a W3C standard
| (https://www.w3.org/TR/xml/) so it _is_ freely available.
| flowerlad wrote:
| Thanks... corrected.
| vendiddy wrote:
| If someone were to release an open source reference
| implementation with s thorough test suite, would that be able to
| work around the lack of a spec?
|
| And beyond that, are there any loopholes to workaround the need
| to pay for a spec?
| brlcad wrote:
| NIST does this on the regular with ISO standards that they're
| involved with. That said, having a reference implementation
| with a test suite doesn't work around anything. Someone needs
| to have access to the standard to create the reference
| implementation. Not really a "loophole" but those on the
| committee that develops a given standard typically have free
| access to draft versions, often even the final version ratified
| by ISO.
| rjsw wrote:
| People on a commitee have free access to the final versions
| of anything that might be helpful to develop future
| standards.
|
| I'm guessing from your username which standards you are
| interested in.
| taylodl wrote:
| So? I'd be happy if people would consistently use RFC 3339
| (https://tools.ietf.org/html/rfc3339). This will solve 99.999%
| you're going to run across. If you're part of that 0.001% who
| actually needs the standard - then it will be worth a few bucks
| to obtain it.
| jedimastert wrote:
| Would https://tools.ietf.org/html/rfc3339#appendix-A be
| copyright infringement?
| pistolpeteDK wrote:
| In my experience (as a European) I found that RFC3339 was
| lacking a few things when it comes to software development;
| especially the usage of 24:00 to mark midnight at the end of a
| day; which is a valid value according to ISO8601(can't remember
| the section).
| taylodl wrote:
| I work for a utility who often needs to work with interval
| data. The last interval of the day is 23:00-24:00 whereas the
| first interval of the day is 00:00-01:00. Some libraries can
| handle that as you'd expect, others can't. A lot of people
| are surprised to see 24:00. The key is 24:00 is the same date
| as 23:00, whereas 00:00 is the next day. It sounds like you
| have a similar need?
| bloak wrote:
| In railway timetables things like 24:37 are sometimes used,
| for example for a train that leaves at 23:45 and arrives at
| 24:37 on weekdays. It would not just be confusing but
| totally incorrect to claim that the train arrives at 00:37
| on weekdays. On the other hand, I don't think I've ever
| seen a 25:xx, and if you were writing a timetable for a
| slow train on the Trans-Siberian Railway then I really
| don't think people would appreciate it if you used a three-
| digit hour.
| vdqtp3 wrote:
| How would that be "totally incorrect"? There are only 24
| hours in a day. It's incorrect to claim that there's 25,
| 26 or 27 hours in the day - even if it's useful and
| proper, it's not technically correct.
| tobylane wrote:
| Think of it as a 24 hour day that starts at (to use UK
| public transport's setup) 4:30. You want the timetable
| and the users to agree on what 8am means, and that 8am
| and the following 2am are the same work day of 24 hours.
| _will_ wrote:
| I'm making a guess here, but I think he means
| specifically the (A) "arrives every weekday at 00:37"
| part. That has a different implied meaning than (B) "the
| train arrives every weekday at 24:37." (A) implies that
| it will arrive every Monday through Friday mornings at
| 00:37 but will not arrive on Saturday or Sunday mornings
| at 00:37. (B) implies that it will arrive Tuesday through
| Saturday mornings at 00:37, but not Sunday or Monday
| mornings.
|
| 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.
| soneil wrote:
| right - 24:37 friday makes is read as "37 past midnight
| on friday night" - which is friday night as humans
| consume time, but saturday morning by the calendar.
|
| 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.
| _trampeltier wrote:
| I have seen 26:xx and 27:xx on work. If we work (very)
| late, our work time system does write it like that.
| the_imp wrote:
| I've seen 25:00 and even 26:00 being used as times, in
| Japan.
| earthboundkid wrote:
| I have also seen 24+ in Japan.
| cbhl wrote:
| For what it's worth, some US train and bus timetables
| will totally write the arrival time as 00:37 or 12:37A.
| It's a localization thing.
|
| 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/englis
| h/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/...
| cynix wrote:
| 25:xx (and even 26:xx) are commonly used in Japan for TV
| programming to indicate that a segment is part of the
| previous day's programme.
| pistolpeteDK wrote:
| Yep - we needed the distinction for a scheduling/rota app.
| Some users had shifts that started at 24:00 and then ended
| sometime during the night. Other users had shifts that
| ended at 24:00. I know that it's common to use 23:59 in the
| latter case, but IMO that's just a poor workaround; and I'd
| argue that 16:00 -> 00:00 is a lot less obvious than 16:00
| -> 24:00.
|
| 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.
| jcrawfordor wrote:
| When I used to work in a 24/7 environment I would quip
| that "it's not tomorrow until the morning crew takes
| over." In a lot of practical situations I think it's
| easier for people to think about the early morning hours
| as being late the previous day. It tends to match shifts
| and reporting cycles better.
| Someone1234 wrote:
| In my experience when people refer to ISO-8601, they generally
| mean RFC 3339 instead anyway.
|
| 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.
| Macha wrote:
| Yeah, there's enough software that only understands ISO-8601 to
| be YYYY-MM-DDThh:mm:ss (with optional Z or +/-xx:xx for a
| offset datetime), that I wouldn't rely on anything more niche
| from the spec.
|
| That does include the period definition format, which I know
| will disappoint some people.
| taylodl wrote:
| > period definition format
|
| You mean the milliseconds? You're correct that YMMV with
| regards to libraries, but a lot of them handle milliseconds
| as well.
| Macha wrote:
| No, I mean stuff like
|
| 2007-03-01T13:00:00Z/P1M
|
| For something that occurs on the first of each month.
| taylodl wrote:
| Oh - combining a date/timestamp and a duration, such as
| xsd:duration
| (http://www.datypic.com/sc/xsd/t-xsd_duration.html). I've
| never seen them combined into a single string, though
| there have been times when that would have been really
| useful!
| em500 wrote:
| It looks like xsd:duration uses duration notation from
| ISO8601. The rules for combining them or designating
| recurring intervals are in ISO8601 section 4.4-4.5 [1].
| Unfortunately, awareness and library support for ISO8601
| interval notation are very sparse and most people/orgs
| just roll their own.
|
| [1] https://www.loc.gov/standards/datetime/iso-
| tc154-wg5_n0038_i...
| JdeBP wrote:
| It's not _freely_ available, i.e. at zero cost. This is not the
| same as not _publicly_ available, which it definitely is.
|
| 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_.
| anticristi wrote:
| Honestly, I don't get why people are complaining. An ISO
| standard costs fraction of what the developer's time reading
| said standard costs. It's almost like complaining that
| electricity and laptops are not free.
|
| 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?
| andyana wrote:
| > An ISO standard costs fraction of what the developer's time
| reading said standard costs.
|
| 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.
| josefx wrote:
| > Well, what if I'm tinkering in my spare time?
|
| 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.
| andyana wrote:
| Sorry, I didn't meant to come across as angry, I'm not.
| I'm just disillusioned with the constant nickle and
| dime'ing in this world. I get it, they need money, but in
| a better world, we wouldn't be charging hobbyist's for
| bits of standard data.
|
| 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.
| josefx wrote:
| I might have overdone it in my response myself. At least
| some ISO standards have draft versions lying around that
| are freely accessible and close enough for most things. I
| think the Wikipedia article on it also cites draft
| versions. Most of the time you can find ways around
| having the finalized standard itself unless you want to
| go the extra mile.
| HenryBemis wrote:
| From experience, every time I have needed an ISO Standard
| (even rare stuff like "ISO 15489-1:2016 Information and
| documentation -- Records management -- Part 1: Concepts
| and principles") I could always go to my client, ask them
| to pay for the bloody thing, so I can show then what
| needs to be done to be 'compliant'. I could alwasys spend
| the $150 (and charge them) but I always wanted THEM to
| retain the 'thing' when I walk away, because if I buy it,
| then I keep it (and no pirated copy for them!)
|
| Any company can afford to pay for the ISOs. It's not for
| hobby (99% of the time).
| matheusmoreira wrote:
| > Most hobbies cost money?
|
| 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.
| anaganisk wrote:
| So show track location, cookies and show ads instead?
| anticristi wrote:
| ... only to find out later it was a click-bait that had
| zero information.
| MaxBarraclough wrote:
| Yes, a software development company could easily afford the
| fee. This misses the point. When we talk about the cost of
| paywalling standards documents, that's not what we mean.
|
| 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]
|
| [0] https://news.ycombinator.com/item?id=26390040
|
| [1] https://news.ycombinator.com/item?id=26390279
| matheusmoreira wrote:
| You're assuming every developer is part of the software
| industry. Not everybody gets paid to work on software.
|
| 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.
| anticristi wrote:
| A document not containing all details necessary for an
| implementation is IMHO not a standard and should not be
| charged for. I'm looking forward to someone asking a refund
| from ISO for an incomplete standard. :)
|
| 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. :)
| matheusmoreira wrote:
| The problem with charging for standards is the fact that
| people _must_ implement them. Since we 're all supposed
| to follow standards, they should be public documents like
| IETF RFCs. Charging money for these things effectively
| erects a massive barrier to entry.
|
| 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:
|
| https://stackoverflow.com/a/60518608/512904
| PinguTS wrote:
| But then: who pays for the infrstructure? For the people
| who does the administration of those standards?
|
| 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".
| dwheeler wrote:
| > But let's assume ISO would publish only high-quality
| standards. Wouldn't those be worth their salt?
|
| 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.
| groby_b wrote:
| No, they wouldn't be worth paying for.
|
| 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.
| ChuckMcM wrote:
| I wonder if fair use would allow me to show one page of the
| standard on my web site. I also wonder if I could find 800 like
| minded people to show one page on their web site :-)
| floatingatoll wrote:
| You would be better off creating a musical number where
| different actors are different fragment commands, like R and
| T and so on, and then using that format to present the entire
| spec verbatim. Certainly you'd be able to claim
| transformative!
| xmprt wrote:
| Fair use doesn't have anything to do with the percentage of
| copyrighted content displayed. Otherwise 100 people could
| just individually display 1 minute of a Disney movie and
| that's obviously not going to happen.
|
| 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.
| ChuckMcM wrote:
| You make a fair point, it is merely a hack to evade a silly
| rule. Since facts are not copyrightable the "right fix" is
| to right an identical standard and make that free, then
| have people adhere to it rather than the ISO one.
|
| 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."
| rsj_hn wrote:
| > You make a fair point, it is merely a hack to evade a
| silly rule. Since facts are not copyrightable the "right
| fix" is to right an identical standard and make that
| free, then have people adhere to it rather than the ISO
| one.
|
| 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.
| dwheeler wrote:
| ISO calls standards that are freely available to the public as
| "publicly available". It's even in the URL for their list:
| https://standards.iso.org/ittf/PubliclyAvailableStandards/
|
| 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.
| kube-system wrote:
| > The standards world is nothing like publishing fiction
| (where the author is normally paid).
|
| ... 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.
| m-p-3 wrote:
| I guess we'll eventually see IsoHub as a branch of SciHub?
| arthur2e5 wrote:
| Library genesis has a standards section, although for some
| reason it's spelled "standards". And it's not that standard-
| rich.
|
| For now Google seems to do the standard-pirating job better,
| partly because it indexes Baidu's Wenku ;)
| colejohnson66 wrote:
| A quick look shows libgen saying "standards" (the correct
| spelling) in multiple places. The URL, OTOH, says "standarts"
| (note the "t")
| agul29 wrote:
| IEC, ISO and BS standards compilations are are all over the
| torrent sites.
| boshomi wrote:
| IsoHub.org belongs to Cuba.
|
| StandardsHub.org is occupied by ISO
| ademarre wrote:
| I would not have my current career if not for the information
| freely available online.
|
| 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.
| robocat wrote:
| It looks to me that about half the revenue for the organisation
| comes from selling ISO standards.
|
| 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
|
| Ideally standards should be free, but how the organisation could
| survive on only half its current revenues would need to be
| addressed.
|
| Edit: removed subtotal rows "34105 Revenue from members", "2559
| Funding of ISO projects"
| javajosh wrote:
| Very nice, thanks. $43M of revenue is a lot more than I
| expected. I wonder what they spend it on?
| speedgoose wrote:
| They are based in Geneva, so 43 millions should be just
| enough for 3 young employees in a basement and an internet
| connection.
|
| More seriously, they spend almost everything on operations.
| It doesn't seem that much to me, good employees are very
| costly.
| danbruc wrote:
| So ISO has 165 member countries, if each one would pays 80k per
| year more than the current membership fee, that would cover the
| lost revenue from sales. That seems almost like a rounding
| error to me.
| JdeBP wrote:
| You need to think it through further. Where do the member
| bodies get this money from?
|
| 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.
| em500 wrote:
| There's a free draft version from the Library of Congress:
|
| 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.)
| hbrav wrote:
| Isn't this going to hamper companies in poorer countries from
| adopting these standards?
| cobaltoxide wrote:
| I suspect that, typically, when people mention ISO-8601, they
| really mean simply "YYYY-MM-DD" and are not seeking to
| incorporate all the other complications and details of the
| standard.
| koblas wrote:
| One should use RFC 3339 dates which have a formal grammar and and
| open standard.
| chrismeller wrote:
| Absolutely. They even reference ISO 8601 in the spec when
| specifying that the T and Z can also be lowercase.
|
| 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.
| d0mine wrote:
| rfc3339 is a profile of iso8601 i.e., every rfc3339 date is
| also iso8601 date but not in reverse
| chrismeller wrote:
| Do you have an example of an 8601 that is not 3339
| compliant? I've never looked at any of the abbreviated
| formats, but if you're giving a full date, time, and offset
| it seems identical (aside from that -).
| ncallaway wrote:
| Sure!
|
| 2021-W07-5
| chrismeller wrote:
| Ahh, you got me. I thought I had mentioned that I had
| never looked at any of the formats for shorter than full
| date, time, and offset strings. D'oh!
| ncallaway wrote:
| I'm _fairly_ sure that 2021-W07-5T00:00:00Z or
| 2000-W03-7T01:23:45.678+09:00 would be a valid full ISO
| date time and offset as well, but I haven't checked the
| specification.
|
| 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.
| [deleted]
| Darkphibre wrote:
| "Funny" story about a _binary_ 8601 implementation.
|
| 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
| ms.
|
| 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.
| opk wrote:
| Your format will have had the advantage of inheriting the
| ISO8601 scheme for representing leap seconds (60 in the
| seconds component). With an epoch, you have to either
| pretend leap seconds don't exist (typical on Unix), know
| when they all were before you can print a time or accept
| the drift (common with GPS units).
| colejohnson66 wrote:
| But... if you're sending the timestamp down to sub-second
| precision, the receiving computer has to compare that
| number to their own time (which is based on an epoch).
| So, an epoch is used either way. It sounds like a
| convoluted solution to a problem that doesn't need to
| exist.
| Darkphibre wrote:
| Hmm? This timestamp is known to be local-time, used for
| measuring durations-between-events on a single session,
| and not used for cross-session reporting. Time would be
| compared from one event to the next.
|
| 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).
| seagreen wrote:
| This gets repeated a lot but unfortunately isn't true.
|
| 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.
|
| Someday someone reading this is going to set out to make a
| new, small specification out of a huge specification.
| Reader, when you start to feel the temptation to make just
| the tiniest improvement-- resist! It's way more useful if
| it's actually a true subset.
|
| 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
| joshuaissac wrote:
| RFC 3339 also allows the offset -00:00 where the UTC time
| is known but the local time is not. The ISO standard does
| not permit this.
| seagreen wrote:
| Ooh, interesting.
|
| 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!
| cies wrote:
| Just judging from what I read iso8601 is based off of rfc3339 (as
| i assume the "request for comments" phase is before the iso
| standardization). ISO slightly improved the rfc, but it is
| largely the same. "Internet RFCs" (if thats the right word for
| the phenomenon) are free, that's the whole point. ISO has taken
| the free (as in speech) and is now selling a derivative work.
|
| 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.
| chrisseaton wrote:
| > Just judging from what I read iso8601 is based off of rfc3339
| (as i assume the "request for comments" phase is before the iso
| standardization).
|
| 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.
| cies wrote:
| thanks for correcting!
| superjan wrote:
| As far as the ISO is concerned, IT business is just one of many
| businesses for which they manage the standards process. ISO has
| to pay the bills somehow, don't they? If they would not charge
| the users of the standards the bill would go to governments
| (effectively taxpayers). As far as taxpayers are concerned, if
| the industry needs standards, they should pay for them
| themselves. There is merit to the argument that free standards
| stimulate innovation, but if governments subsidize the
| industry, they will prefer to subsidize their national
| industry, not world wide.
| dharmab wrote:
| That's how the ISO standards body works- you pay access for the
| spec to fund the ISO's development of standards.
|
| https://www.youtube.com/watch?v=nAsrsMPftOI
| cogwheel wrote:
| The same is true for the standard that sets A to 440 Hz.
|
| Though they spoil the plot in the abstract.
|
| https://www.iso.org/standard/3601.html
| matheusmoreira wrote:
| Huh, so this is where musical notes come from? I thought they
| had always been like that, never expected to find some ISO
| standard behind it all.
| kube-system wrote:
| Most standards are not where ideas come from, but instead,
| they are simply people who took the time to write down an
| idea someone else had.
|
| https://en.wikipedia.org/wiki/A440_(pitch_standard)#History_.
| ..
| Jap2-0 wrote:
| Putting aside that notes don't really have to be in tune to
| be notes, this is not where A=440hz originated.
|
| 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...
| chrismorgan wrote:
| Eww, only 0.5 Hz tuning accuracy on that 440 Hz? That's two
| cents (2/100 of a semitone). As an amateur with a not-terribly-
| high-quality piano I'd be ashamed to tune it two cents off; you
| really want to get within one (and you need the difference
| between same-pitched strings to be a good deal finer than
| that). I'd expect less than half a cent from a professional
| tuner on a decent-quality piano.
|
| 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.
| xyproto wrote:
| 440 Hz?! Preposterous. 432 for life!
| dkdbejwi383 wrote:
| For the uninitiated:
| https://www.youtube.com/watch?v=EKTZ151yLnk
| wincy wrote:
| Only 38 Swiss Francs (~40USD, ~35EUR) to review this standard!
| So if I want to make an ISO standard instrument do I need to
| buy all the other notes too?
| anticristi wrote:
| Only if you don't know how to multiply and divide frequencies
| by 2^(1/12).
| cogwheel wrote:
| no, you just need to multiply 440 by (12th root of 2)^k,
| where k is the number of half-tones above (pos) or below
| (neg) A440
| rezonant wrote:
| only if it's equal temperament :-)
___________________________________________________________________
(page generated 2021-03-09 23:01 UTC)