Editing 2562: Formatting Meeting
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
| Latest revision | Your text | ||
| Line 18: | Line 18: | ||
{{w|ISO-8601}} (that is, standard number 8601 as promulgated by the {{w|International Organization for Standardization}} since 1988) specifies a date format of YYYY-MM-DD (e.g., 2021-12-31), which results in dates being listed in chronological order when sorted stringwise. The ISO format is called "{{w|big-endian}}", which refers to the fact that the most significant unit in the date (the year) comes first. The European format is instead "{{w|little-endian}}", as the front-end value represents the finest possible distinction the date can convey - the particular day. The American format is "{{w|middle-endian}}", or occasionally "mixed-endian", since the value given first is the one which is neither the one with greatest significance nor the most precise. | {{w|ISO-8601}} (that is, standard number 8601 as promulgated by the {{w|International Organization for Standardization}} since 1988) specifies a date format of YYYY-MM-DD (e.g., 2021-12-31), which results in dates being listed in chronological order when sorted stringwise. The ISO format is called "{{w|big-endian}}", which refers to the fact that the most significant unit in the date (the year) comes first. The European format is instead "{{w|little-endian}}", as the front-end value represents the finest possible distinction the date can convey - the particular day. The American format is "{{w|middle-endian}}", or occasionally "mixed-endian", since the value given first is the one which is neither the one with greatest significance nor the most precise. | ||
| − | In the above, the 'value groups' are not usually internally checked for '{{w|Endianness|endianness}}', but regular numerals are also usually written with the largest place values on the left – for example, the first 2 in {{w|2021}} is the thousands place – though whether this convention is big-endian or little-endian depends on whether the writing system of such numbers is in the context of left-to-right or right-to-left text. The concept of | + | In the above, the 'value groups' are not usually internally checked for '{{w|Endianness|endianness}}', but regular numerals are also usually written with the largest place values on the left – for example, the first 2 in {{w|2021}} is the thousands place – though whether this convention is big-endian or little-endian depends on whether the writing system of such numbers is in the context of left-to-right or right-to-left text. The concept of endianess is most often used in reference to the storage order, whether of indivisible binary bits or of values built up of successive value groups. Pairs of hexadecimal values are individually usually represented in big-endian 'numeric' order, where bitwise distinctions are not necessary, but it is useful to know if a system stores a multibyte value in big-endan or little-endian packing, i.e., whether the value 0x01 0x02 (values 1 and 2, on their own) is treated as a value of 258 (0x01*256 + 0x02*1) or 513 (0x01*1 + 0x02*256). (The term was taken in inspiration from a [https://www.ling.upenn.edu/courses/Spring_2003/ling538/Lecnotes/ADfn1.htm Jonathan Swift story] about a war over which end of a boiled egg one was to cut into, a useful metaphor for many other situations where diametrically opposed self-justifications for one ''or'' another practice may lead to standing by vague principles rather than agreeing upon a unifying resolution.) This standard was also mentioned in [[1179: ISO 8601]] and used in [[1340: Unique Date]]. |
The joke in the title text is that it appears some people attempted to interpret the improperly formatted date as if it were expressed in the more ISO-8601 style of format of "Y/M/D". They read the date as ''20''02, March 22, so they already went to their meeting almost 20 years ago. Unless the announcement of the meetings was made 2 decades in advance, there's a {{w|Paradox|paradox}} that these participants would have taken the date from an announcement in the far future. However, a strict interpretation of the date would make this incorrect: ISO-8601 format specifies four-digit years (which also avoids having to assume the century), two-digit months, and two-digit days. Therefore "2/3/22” ''can by specification not'' be an ISO-8601 date, as "2" can only be rendered as "0002", and "3" must be "03". Even if the leading {{w|0|zeroes}} were omitted in violation of ISO-8601, the year would become {{w|AD 2|Year 2}}, not Year 2002. Since the standard always uses a 4 digit 'YYYY' format in the first field, and no common formatting uses YYYY-DD-MM, any date written in ISO-8601 is easily recognized and (comparatively) {{w|Ambiguity|unambiguously}} interpretable as YYYY-MM-DD. Dates written as if Y-M-DD or other distortions should be considered formatted improperly, and unwisely. | The joke in the title text is that it appears some people attempted to interpret the improperly formatted date as if it were expressed in the more ISO-8601 style of format of "Y/M/D". They read the date as ''20''02, March 22, so they already went to their meeting almost 20 years ago. Unless the announcement of the meetings was made 2 decades in advance, there's a {{w|Paradox|paradox}} that these participants would have taken the date from an announcement in the far future. However, a strict interpretation of the date would make this incorrect: ISO-8601 format specifies four-digit years (which also avoids having to assume the century), two-digit months, and two-digit days. Therefore "2/3/22” ''can by specification not'' be an ISO-8601 date, as "2" can only be rendered as "0002", and "3" must be "03". Even if the leading {{w|0|zeroes}} were omitted in violation of ISO-8601, the year would become {{w|AD 2|Year 2}}, not Year 2002. Since the standard always uses a 4 digit 'YYYY' format in the first field, and no common formatting uses YYYY-DD-MM, any date written in ISO-8601 is easily recognized and (comparatively) {{w|Ambiguity|unambiguously}} interpretable as YYYY-MM-DD. Dates written as if Y-M-DD or other distortions should be considered formatted improperly, and unwisely. | ||
