I switched to it in my later teens when I realised how many cases it would be better in.
Conversion during conversation might be an extra step, but I’ll be pushing for the next generation to have this by default.
Also, much better when using for file names.
Also, YYYY-MM-DD. There’s a reason why it is the ISO
The conversion is pretty much the only hurdle I ever hear about, but that’s easy enough. How many songs/films talk about “if I could rewind the last 12+12 hours”…it’s just a matter of making it fit in context people can understand when they know a day is 24 but are used to 12.
ISO and while we’re at it, the NATO phonetic alphabet for English speakers. “A as in apple B as in boy” means fuck all when you’re grasping for any word that starts with that letter, and if English isn’t your first language fuckin forget about it.
ISO and while we’re at it, the NATO phonetic alphabet for English speakers. “A as in apple B as in boy” means fuck all when you’re grasping for any word that starts with that letter, and if English isn’t your first language fuckin forget about it.
The radio words were chosen to be distinct, such that for people who trained in them, it would be easier to distinguish letters being spoken over low quality radio.
Not very relevant in the era of 2G HD audio, and now VoLTE.
But when there’s a bad signal and you have to tell someone a callsign, it makes sense.
I like ISO, because in whatever cases I have interacted with it, it has made programming easier for me.
I like YYYY-MM-DD, because when files lose their metadata, if they are named using this, I can still sort by name and get results by date.
I’m pretty sure that’s an example of why you should use the chosen ones instead of going “mancy/nancy” all over the place.
Also, didn’t they just make a standard for themselves and other just took it because it was probably easier than making one for their own language (oh right, NATO… but let’s be honest here, NATO is just a forum for America to flaunt its power while PR-ing peaceful, so it makes sense they use English, which is also easier to be a second language than most other ones).
Though I feel like China might have made their own.
Right, and the most significant bit of the whole date is the first Y in YYYY, which we can’t put at the end unless we reverse the year itself. So we can either have pure big-endian, or PDP-endian. I know which one I’m picking.
Your literal statement is also just wrong. The solitary implication of endianness is byte ordering, because individual bits in a byte have no ordering in memory. Every single one has the exact same address; they have significance order, but that’s entirely orthogonal to memory. Hex readouts order nybbles on the same axis as memory so as not to require 256 visually distinct digits and because they only have two axes; that’s a visual artefact, and reflects nothing about the state of memory itself. ISO 8601 on the other hand is a visual representation, so digit and field ordering are in fact the same axis.
Every single one has the exact same address; they have significance order, but that’s entirely orthogonal to memory.
We are talking about transferring data, not storing it. For example SPI allows both for LSb-first and MSb-first. In date digit-number-date is like bit-byte-word.
Right, and in data transfer every byte can be placed in an absolute order relative to every other. And the digits within the respective fields are already big-endian (most significant digit first), so making the fields within the whole date little-endian is mixed-endian.
I have iterated this several times, so I worry there’s a fundamental miscommunication happening here.
Ok, I think I see the problem. To me, MSb (Most Significant bit) isn’t an ordering at all, just a label that one particular bit has. To specify an ordering, you’d also need to say whether that bit comes first or last. This concept doesn’t exist in computer memory because, as previously mentioned, bits in a byte aren’t ordered in memory. I was thinking of the individual digits in a field (each Y in YYYY) as separate bytes in a word, so endianness order makes sense to think about; separate fields in this analogy were contiguous like struct fields. I think my mental model is sensible, since ISO 8601 is fundamentally a sequence of characters, which are all in an absolute order.
I switched to it in my later teens when I realised how many cases it would be better in.
Conversion during conversation might be an extra step, but I’ll be pushing for the next generation to have this by default.
Also, much better when using for file names.
Also, YYYY-MM-DD. There’s a reason why it is the ISO
Anti Commercial-AI license
The conversion is pretty much the only hurdle I ever hear about, but that’s easy enough. How many songs/films talk about “if I could rewind the last 12+12 hours”…it’s just a matter of making it fit in context people can understand when they know a day is 24 but are used to 12.
ISO and while we’re at it, the NATO phonetic alphabet for English speakers. “A as in apple B as in boy” means fuck all when you’re grasping for any word that starts with that letter, and if English isn’t your first language fuckin forget about it.
err… didn’t get what you’re trying to say
The radio words were chosen to be distinct, such that for people who trained in them, it would be easier to distinguish letters being spoken over low quality radio.
Not very relevant in the era of 2G HD audio, and now VoLTE.
But when there’s a bad signal and you have to tell someone a callsign, it makes sense.
I like ISO, because in whatever cases I have interacted with it, it has made programming easier for me.
I like YYYY-MM-DD, because when files lose their metadata, if they are named using this, I can still sort by name and get results by date.
Anti Commercial-AI license
We standardized an alphabet among all countries for clear communication.
Here is an example of it going wrong.
I knew this would be the video. 😂
Here is an alternative Piped link(s):
wrong.
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
I’m pretty sure that’s an example of why you should use the chosen ones instead of going “mancy/nancy” all over the place.
Also, didn’t they just make a standard for themselves and other just took it because it was probably easier than making one for their own language (oh right, NATO… but let’s be honest here, NATO is just a forum for America to flaunt its power while PR-ing peaceful, so it makes sense they use English, which is also easier to be a second language than most other ones).
Though I feel like China might have made their own.
Anti Commercial-AI license
Conversion is always extra step, but you don’t need it if you use same timezone as other participant.
Big-endian is big. Alternatively DD.MM.YYYY or DD.MM.YY for little-endian lovers.
Except no because the digits themselves are still big-endian. That’s nUxi.
It’s more along the lines of most signigicant bit/least significant bit, rather then byte order.
Right, and the most significant bit of the whole date is the first Y in YYYY, which we can’t put at the end unless we reverse the year itself. So we can either have pure big-endian, or PDP-endian. I know which one I’m picking.
Your literal statement is also just wrong. The solitary implication of endianness is byte ordering, because individual bits in a byte have no ordering in memory. Every single one has the exact same address; they have significance order, but that’s entirely orthogonal to memory. Hex readouts order nybbles on the same axis as memory so as not to require 256 visually distinct digits and because they only have two axes; that’s a visual artefact, and reflects nothing about the state of memory itself. ISO 8601 on the other hand is a visual representation, so digit and field ordering are in fact the same axis.
We are talking about transferring data, not storing it. For example SPI allows both for LSb-first and MSb-first. In date digit-number-date is like bit-byte-word.
Right, and in data transfer every byte can be placed in an absolute order relative to every other. And the digits within the respective fields are already big-endian (most significant digit first), so making the fields within the whole date little-endian is mixed-endian.
I have iterated this several times, so I worry there’s a fundamental miscommunication happening here.
big-endian (most significant byte or in our case number first).
Digit in base2 is bit. Endianess is byte order, not bit order. MSb-first is bit order.
Ok, I think I see the problem. To me, MSb (Most Significant bit) isn’t an ordering at all, just a label that one particular bit has. To specify an ordering, you’d also need to say whether that bit comes first or last. This concept doesn’t exist in computer memory because, as previously mentioned, bits in a byte aren’t ordered in memory. I was thinking of the individual digits in a field (each Y in YYYY) as separate bytes in a word, so endianness order makes sense to think about; separate fields in this analogy were contiguous like struct fields. I think my mental model is sensible, since ISO 8601 is fundamentally a sequence of characters, which are all in an absolute order.