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.
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.
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).
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?
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.
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".
Times greater than 24:00 are not allowed by ISO 8601.
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.
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.
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.
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.
An app I have to track habits and streaks lets you specify the time to count as "that day". I often walk my dog after midnight, so I have this set to 3am.
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.
Google's GTFS spec, which is a spec for defining transit schedules among other things, allows for times greater than 24:00:00 to represent arrival and departure times on the following day for a given transit schedule.
I did have to use 25:xx to log some late nights working at my last job in Japan. It was very weird to me, but that's how they wanted it. If it was part of the current workday, then it wouldn't reset to 0:00.
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.
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.
It's not tomorrow until I've been to sleep. It's not the morning until I've had a cup of coffee. Time is incredibly subjective. Clocks need to agree, but nomenclature does not.
I had a software project where I thought I could infer which shift was working from the time (because shift-related metrics were really important). I learned very quickly that shift and time, though related, are really separate data points.
Part of the problem is that midnight doesn't have a date. But we pretend it does because that's much easier to program. Similarly, noon is neither A.M. nor P.M. but we pretend it is P.M. because that's easier to program. Both cases were very understandable compromises in the early days of computing but now we have both the processing power and storage to do things correctly but because of legacy inertia, we'll keep on going pretending things that aren't true are true.
In practice the intervals don't overlap as they're understood as follows [23:00-24:00) and [00:00-01:00). That is the interval begins precisely at 23:00 or 00:00, but ends as close to the endpoint as your timing resolution allows. This way we don't have to write cumbersome expressions such as 23:00-23:59:59.999.
as a software developer who is constantly frustrated by ambiguous and confusing datetime representations, i'm really glad that your 24:00 display isn't in the spec. that's exactly the sort of thing that leads to bloated specs and programmers complaining about what a PITA dates are.
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.
Personally I think that supporting 24:00 is the wrong way to go. 23:59:59.9999 or <next day> 00:00:00.0000 should suffice in any situation I can think of. It's just a case of being overly fanciful, wanting 24:00.
The problems with 23:59:59.9999 etc are aliasing and granularity issues, i.e. breaks and overlaps when used as intervals or inequalities, and the consequences may be anything from innocuous (calendar alarms) to catastrophic (financial reporting).
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 }
and can be pronounced "all times from and including midnight onwards, until (but strictly excluding) midnight the next day". These half-open intervals correspond advantageously to the continuously linear assumptions of chronometric time, with two properties of critical relevance: they can be recorded via commonplace machine representations of timestamps; and, they may be compared, subdivided, and concatenated without inadvertent breaks and overlaps. These qualities eliminate most aliasing & granularity concerns.
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.
Sure, but just because it skips out on practical considerations, doesn't mean the RFC is irrelevant. The standard format is still helpful even if the semantics are underspecified.
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.
After learning some more about the practicalities of time/date throughout my career, it always seemed a bit odd to me to even support the +/- thing... but maybe I'm missing something. My reasoning is: If it's a timestamp (i.e. it's a point on the physical time line, relativity notwithstanding), Z should be fine and unambiguous. If it's a local date/time then you need the actual legal time zone (e.g. Europe/Berlin, or whatever.) since those can and have changed historically. Sure, you can encode that as an offset for any given instant if you're actually talking about "now" or the past, but that's a lossy encoding and you can't really talk about future events using an offset.
My understanding is that it is because it changes historically that you'd rather want +/- (an absolute measure) rather than Continent/Location denonimation (a measure that is bound to change).
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.
Right, for explicitly recording a timestamp without having to refer to a historical time zone database it would seem to make a tiny bit of sense... but recording the actual time zone would work just as well for historical data and future times. I just have a hard time imagining a scenario where you really care about the offset... the timestamp itself is enough.
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.
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!
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.
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.
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.
> 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.
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?
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.
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. :)
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:
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".
Participation in the IETF is mostly free - you can join the mailing lists and discuss the drafts. What costs is going to the physical meetings: there’s an attendance fee, as well as costs for travel and accommodation, etc.
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.
> 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.
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.
> 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.
Some time ago, I lost my job and subsequently cashed in my RRSPs. After moving to a tiny 80 year old farm house in the middle of nowhere, hooked up with 10 Mbps of broadband and a couple years of runway saved up.... I have all the time in the world. I don't have any money to spend on bits and bytes, however. If tomorrow I wake up wanting to do work related to ISO 8601 (say translating it to Klingon), I don't think I'd be easily able to. That's a problem, in my opinion...
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.
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.
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.
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).
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]
> Honestly, I don't get why people are complaining. An ISO standard costs fraction of what the developer's time reading said standard costs.
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.
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 :-)
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.
That's not actually true. Fair use involves four factors:
(1) the purpose and character of the use, including whether such use is of a commercial nature or is for nonprofit educational purposes; (2) the nature of the copyrighted work; (3) the amount and substantiality of the portion used in relation to the copyrighted work as a whole; and (4) the effect of the use upon the potential market for or value of the copyrighted work.
(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.
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."
> 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.
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!
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 €20, compared with the €200 for the official ISO version. So there are options...
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.
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”
How they should survive? e.g. by 20 governments realizing that the friction this bullshit adds is costing their country more than 1 million, and each contributing 1M of tax money.
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.
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.
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.
I suspect most of the operations costs come from doing things in their obsolete way.
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.
Come on, we are talking about $20 million! I don’t think half their staff are dedicated to billing and website design related to the sale of ISO standards.
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.
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?
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.
Funny. I was reading about the Schiller institute just today. They are a crazy bunch, and for some reason they chose (among a great deal of actually legitimate figths they have) to have an opinion on that.
As an orchestra musician, I don't believe an orchestra can ever go down below 440. Trying to play any modern wind instrument at those pitches would sound awful and just pitching them down would not work. If I would go to Heckel (the bassoon brand I play, because they have been the best (and most expensive by far) for about 200 years) and ask them to make a 432hz-pitched bassoon they would laugh at me.
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.
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.
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.
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.
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"."
Sure would be nice if we could read the spec online:)
the author of GNU "date" says: "… This paragraph was put into the RFC at my suggestion, precisely so that GNU "date" output wouldn't have to contain that "T". …" https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39693#15
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]
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 -).
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.
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.
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.
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).
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).
(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.)
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.
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."
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.
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.
> 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.
> 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.
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.
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.
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.
Yeah exactly, I'd even go as far as saying that the standard is only useful if you're implementing a compiler or tracking down a bug in an existing one.
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.
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.
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.”
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
> 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.
> 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.
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.
You know, it's really easy to skip over an article you don't care about, and move on to one that you do.
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.
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.
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.
