Difference between revisions of "2562: Formatting Meeting"
(→Explanation: Removed some stuff to get the explanation more to the point) |
|||
(10 intermediate revisions by 8 users not shown) | |||
Line 10: | Line 10: | ||
In the {{w|United States}}, it's common to write {{w|Calendar dates|dates}} numerically in the {{w|Calendar date#Date format|format}} ''{{w|Month|month}}/{{w|Day|day}}/{{w|Year|year}}'' -- 2/3/22 means February 3, 2022 (the century is often omitted when it's obvious that the date is around the current time). In Europe, the {{w|Calendar date#Gregorian, day–month–year (DMY)|usual order}} is ''day/month/year'' - so 2/3/22 is 2nd March, 2022. | In the {{w|United States}}, it's common to write {{w|Calendar dates|dates}} numerically in the {{w|Calendar date#Date format|format}} ''{{w|Month|month}}/{{w|Day|day}}/{{w|Year|year}}'' -- 2/3/22 means February 3, 2022 (the century is often omitted when it's obvious that the date is around the current time). In Europe, the {{w|Calendar date#Gregorian, day–month–year (DMY)|usual order}} is ''day/month/year'' - so 2/3/22 is 2nd March, 2022. | ||
− | "{{w|Internationalization and localization|Localization}}" is the technique used in software to make it accept input and display output in the formats most natural to users in their locations. For example, in the United States numbers use commas "," to separate thousands and a {{w|Decimal separator#Countries using decimal point|decimal point}} "." to separate the decimal values, while in large areas of the EU {{w|Decimal separator#Countries using decimal comma|it is the reverse}}. And the textual output will be translated to the local language. Naturally, this also includes displaying dates in the local format, as described above. Localization may also include the adoption of the tax law to the location, for instance when adopting tax software made for the US to the UK. | + | "{{w|Internationalization and localization|Localization}}" (also known as L10N) is the technique used in software to make it accept input and display output in the formats most natural to users in their locations. For example, in the United States numbers use commas "," to separate thousands and a {{w|Decimal separator#Countries using decimal point|decimal point}} "." to separate the decimal values, while in large areas of the EU {{w|Decimal separator#Countries using decimal comma|it is the reverse}}. And the textual output will be translated to the local language. Naturally, this also includes displaying dates in the local format, as described above. Localization may also include the adoption of the tax law to the location, for instance when adopting tax software made for the US to the UK. |
− | The joke in this {{w|Comics|comic}} is that two dates are shown, on the same {{w|Display device|display}}, relating to meetings regarding localization. The date of the meeting of the US team is localized in the US format while the EU team's meeting is localized in the European format, and these two dates (about a month apart) happen to be formatted the same | + | The joke in this {{w|Comics|comic}} is that two dates are shown, on the same {{w|Display device|display}}, relating to meetings regarding localization. The date of the meeting of the US team is localized in the US format while the EU team's meeting is localized in the European format, and these two dates (about a month apart) happen to be formatted the same. [[Cueball]] needs to explain that the European meeting will be a month later than the US meeting to avoid any confusion due to the ambiguity. Which is {{w|Irony|ironic}}, since the aim of localization is to reduce such {{w|Confusion|confusion}}. |
A further interpretation, which extends also into the title text, is that these groups may have been supposed to meet on the same day. But even the committee that was supposed to fix these problems messed this up. Cueball may be 'explaining' the staggered approach to cover up that the two groups are already reading the date(s) for the meeting quite differently. | A further interpretation, which extends also into the title text, is that these groups may have been supposed to meet on the same day. But even the committee that was supposed to fix these problems messed this up. Cueball may be 'explaining' the staggered approach to cover up that the two groups are already reading the date(s) for the meeting quite differently. | ||
− | {{w|ISO-8601}} | + | {{w|ISO-8601}} 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. |
− | + | 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. | |
− | |||
− | 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 | ||
==Transcript== | ==Transcript== |
Latest revision as of 10:18, 1 July 2024
Formatting Meeting |
![]() Title text: Neither group uses iso 8601 because the big-endian enthusiasts were all at the meeting 20 years ago. |
Explanation[edit]
In the United States, it's common to write dates numerically in the format month/day/year -- 2/3/22 means February 3, 2022 (the century is often omitted when it's obvious that the date is around the current time). In Europe, the usual order is day/month/year - so 2/3/22 is 2nd March, 2022.
"Localization" (also known as L10N) is the technique used in software to make it accept input and display output in the formats most natural to users in their locations. For example, in the United States numbers use commas "," to separate thousands and a decimal point "." to separate the decimal values, while in large areas of the EU it is the reverse. And the textual output will be translated to the local language. Naturally, this also includes displaying dates in the local format, as described above. Localization may also include the adoption of the tax law to the location, for instance when adopting tax software made for the US to the UK.
The joke in this comic is that two dates are shown, on the same display, relating to meetings regarding localization. The date of the meeting of the US team is localized in the US format while the EU team's meeting is localized in the European format, and these two dates (about a month apart) happen to be formatted the same. Cueball needs to explain that the European meeting will be a month later than the US meeting to avoid any confusion due to the ambiguity. Which is ironic, since the aim of localization is to reduce such confusion.
A further interpretation, which extends also into the title text, is that these groups may have been supposed to meet on the same day. But even the committee that was supposed to fix these problems messed this up. Cueball may be 'explaining' the staggered approach to cover up that the two groups are already reading the date(s) for the meeting quite differently.
ISO-8601 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 "big-endian", which refers to the fact that the most significant unit in the date (the year) comes first. The European format is instead "little-endian", as the front-end value represents the finest possible distinction the date can convey - the particular day. The American format is "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.
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 2002, March 22, so they already went to their meeting almost 20 years ago.
Transcript[edit]
- [A screen is shown which displays five rows of text, the top three above a dividing line. To the right of the screen the upper part of Cueball is visible as he delivers a message concerning the text on the screen:]
- Localization working group
- Upcoming meetings
- -----------------
- US Team: 2/3/22
- EU Team: 2/3/22
- Cueball: And the European formatting and localization team will meet a month later...
![comment.png](/wiki/images/0/03/comment.png)
![comment.png](/wiki/images/0/03/comment.png)
![Icons-mini-action refresh blue.gif](/wiki/images/e/e5/Icons-mini-action_refresh_blue.gif)
Discussion
I downloaded and ran theusaf's bot from its website to make this page. Not sure how to give page creation permission to User:Baffo32RunningTheusafBOT. When you run the bot you notice that Theusaf's username is "the usa f". 172.70.110.45 16:02, 31 December 2021 (UTC)
- The bot should be back up. The hosting service has some maintenance, which turned it off. theusaf (talk) 01:25, 2 January 2022 (UTC)
shouldn't it be ISO, not iso? actually, the whole title text is lowercase-d when I feel like it shouldn't be 172.70.35.70 16:59, 31 December 2021 (UTC)Bumpf
- you're probably right. as a geek, one uses lowercase 'iso' all the time in computer date code where it is usually lowercase. e.g. i type `date --iso=seconds` every day into my linux terminal; it outputs 8601 format. 172.70.114.167 19:23, 31 December 2021 (UTC)
Speaking as a European, we'd often read 2/3/22 as "2nd March 2022" (same order as the numbers), not "March 2, 2022", though obviously we'd understand both expressions. Also, the suggestion that the thousands/decimal punctuation is reversed in the EU is wrong, as this does not apply to all countries of the EU. For example, Ireland uses the same as the US (and the same as the UK, though that is no longer part of the EU and might eventually give up decimalisation altogether on account of fractions being more wholesome...) Rotan (talk) 18:47, 31 December 2021 (UTC)
- You mean the 12-times-tables, that I was thoroughly taught when I was young, might (literally) gain currency once more? That'll be interesting! 172.70.85.73 16:42, 1 January 2022 (UTC)
Another comic which references ISO-8601 is: https://xkcd.com/1179/ Rps (talk) 21:27, 31 December 2021 (UTC)
It's been more than 20 years since in 'casual' date writing I started prefering "D/Mmm/YYYY" format (today is 31/Dec/2021, for me right now, tomorrow is 1/Jan/2022) when I had a totally free hand. A combination of indicating to US colleagues in my multinational company of that time that I wasn't writing trying to write Jan/1/2022 (not that it would matter in that particular case!) and doing my bit to support the upcoming Y2K-compatability issues that other people were gradually getting to know about. Though for coded dates, YYYYMMDD[.hh[mm[ss[...]]]] always worked best for me. It numerically sorts (it will even when YYYY eventually becomes YYYYY!) and can be given arbitrary sub-day specification - at least until float-rounding errors start to creep in. 172.70.90.43 22:25, 31 December 2021 (UTC)
- Elements of Style already recommended the Notation D Mmm YYYY already in 1923. It is the only sensical solution to the problem other than the technical ISO 8601. --172.68.110.121 09:07, 3 January 2022 (UTC)
Around year 2000 there was short time when people were writing the years properly. Afterwards, the laziness won again and people started using just two digits again ... sigh ... -- Hkmaly (talk) 01:19, 1 January 2022 (UTC)
Is localization spelled localisation in countries that use English? Boatster (talk) 01:59, 1 January 2022 (UTC)
- It is. Obviously that excludes the US and any other past colonials who picked up the wrong habit along the way. ;) 172.70.86.22 02:18, 1 January 2022 (UTC)
- Actually, the -ise/-ize distinction only came in in UK English quite recently and some UK publishers still use -ize endings. I was told both endings were OK at school in the UK in the sixties.172.70.86.68 09:46, 1 January 2022 (UTC)
- I treat the Oxford Spelling with the respect I give the Oxford Comma. None. (My own '70s education drummed that into me, and it's not going to change easily.) 172.70.90.71 11:56, 1 January 2022 (UTC)
Anyone who doesn't use ISO-8601 dates should be shot on sight. SDSpivey (talk) 10:24, 1 January 2022 (UTC)
I got the impression that slashes as separators mark us-notation and dashes EU notation. 162.158.88.139 11:36, 1 January 2022 (UTC)
- The UK complicated this notation (don't we always!). We typically use 'European' ordering (or maybe they use ours?) but also slashes (whichever side of the Atlantic that started). This makes it not so easy to just assume dd-mm-yyyy and mm/dd/yyyy differentiate by separator used. Not sure how to rewrite "In Europe, the usual order is day/month/year - although the slash is rarely used as the separator" in light of this. Are we 'rare' in Europe, or no longer to be considered that at all and therefore not even discussed? 172.70.85.73 16:38, 1 January 2022 (UTC)
- In France we mainly use slashes, with DD/MM/(YY)YY, so yeah not at all and we're always really confused with USian dates, even more because it's not reflected in our language (January the 2nd of 2022 => 2 janvier 2022). 108.162.229.233 19:16, 1 January 2022 (UTC)
- Don’t you mean 13 Nivôse CCXXX --172.70.131.70 06:26, 5 January 2022 (UTC)
- In Denmark we usually write 2/3 2022 for March 2nd. I would of course prefer 2022-03-02. --Kynde (talk) 13:48, 3 January 2022 (UTC)
- In Germany we use dots as separators: 2022-03-02 => 02.03.2022 or 02. März 2022. --141.101.104.8 15:04, 5 January 2022 (UTC)
The discussion of currency seems way too much for something that isn't actually part of the comic. I believe it would be better in trivia, if part of the article at all. Nitpicking (talk) 13:36, 1 January 2022 (UTC) -- concur with that. Its also annoying as on the east of the atlantic, I'd be writing 10^5 as 100,000 not 100.000
In Sweden we use ISO-8601 (YYYY-MM-DD, 2022-03-02), but it is also common to use YY-MM-DD (22-03-02) or YYMMDD (220302). And the bastard D/M-YY (3/2-22). 141.101.104.14 22:17, 2 January 2022 (UTC)
Isn't the joke really that there was originally only one localization working group, but they were inept at localization? The group set a date for its next meeting, but did not consider that people in different regions would interpret the date differently. Now, in order to cover up their incompetence, the group is pretending they meant to have two separate meetings based on the two interpretations of the date. At least, I thought that was funnier... 172.70.114.253 (talk) (please sign your comments with ~~~~)
Since everyone is adding the common formats from their European country here is the traditional German one: dd.mm.(yy)yy - so the 2nd of March this year would be 2.3.22 (or 2.3.2022 - or even to show that there is something omitted: 2.3.'22) Haven't seen a slash or dash being used in date formatting by a German who is writing in German. But working in an international setting of course brings forward all kinds of hybrids, when Germans write in English, etc. --Lupo (talk) 08:17, 5 January 2022 (UTC)
- With a leading null (if necessary) for dd.mm.yy is vastly more common: 02.03.09 is 2009-03-02. --141.101.104.8 15:04, 5 January 2022 (UTC)
For this reason and this reason alone I have always timed the dates I have important identity documents issued to not happen on the first 12 days of a calendar month. I have so far been quite successful with that, and possess no identity document issued before the 13th of any month. I don't know how much it saves me in filling all sorts of official documents and visa forms but I know people who got into trouble because of this confusion and been held back in immigration or other places. My birthday also happens to be later in the month so that's not a problem although not by my design at least. Yes, I know that having the day of the month the same as the month also avoids this confusion, but trying to predict the issue date of documents based on the application date that precisely is not within my abilities. Arikb (talk) 10:57, 19 January 2022 (UTC)
My alt caption: “100,000 attendees are expected.” -- 108.162.250.234 (talk) 12:08, 30 January 2022 (UTC) (please sign your comments with ~~~~)
- That works, or alternatively we could have "10.500" which suggests dividing someone in half, but becomes unambiguous because that makes no sense.--Twisted Code (talk) 02:47, 28 July 2023 (UTC)
I think whoever wrote the last paragraph of the explanation might bbe overthinking it. The title text doesn't say anything about the ISO specification, only big endianness. People who put the most significant digits first, big Indians, could have —regardless of ISO— interpreted the date as March 22, 2002. I think that paragraph should be rewritten but it's too big for me to rewrite when my brain is about ready to sleep (And I'll probably forget after I do sleep). Anyone more awake want to give it a try?--Twisted Code (talk) 03:01, 28 July 2023 (UTC)