explain xkcd - User contributions [en]

Talk:1557: Ozymandias

2015-07-29T13:56:33Z

Ulm:

Look upon this comment and despair! {{unsigned ip|173.245.50.164}}

So... [http://dwarffortresswiki.org/index.php/Planepacked Planepacked]? [[Special:Contributions/173.245.50.145|173.245.50.145]] 05:44, 29 July 2015 (UTC)

The page seems to give a description, but not an explanation of the joke. I still don't get it! Why has Ozymandias been singled out for this treatment? Is there some way in which recursion is particularly appropriate or inappropriate in this case, or has it just been selected arbitrarily? Is the whole joke that recursion is inherently funny? Normally when recursion is used in XKCD it's making a larger point, or cleverly riffing on something in particular. This isn't just Describe XKCD, so I'd love to see an explanation of this comic. [[Special:Contributions/141.101.99.47|141.101.99.47]] 09:35, 29 July 2015 (UTC)

:May it be that Ozymandias is chosen because of Smith’s poem, where at last London has vanished, suggesting that Shelley’s poem is the last remains of British civilization? --[[Special:Contributions/162.158.91.193|162.158.91.193]] 10:04, 29 July 2015 (UTC)

In Germany, we have a childrens’ song „Ein Mops kam in die Küche“, which translates as follows (there are slightly different versions, though):

A pug came into the kitchen / and stole an egg from the chef. / Then the chef took his knife / and mashed the pug. // Then many pugs came / to his grave / and set a memorial for him, / where these words were written: // “A pug came into the kitchen …”

Maybe something similar exists in English? --[[Special:Contributions/162.158.91.193|162.158.91.193]] 10:04, 29 July 2015 (UTC)

:We have:

: This is the song that doesn't end, / Yes, it goes on and on, my friend, / Some people started singing it not knowing what it was, / And they'll continue singing it / Forever, just because [repeat]

:There's also:
::I know a song that gets on everybody's nerves, everybody's nerves, everybody's nerves,
::I know a song that gets on everybody's nerves and this is how it goes...[repeat]

:''— [[User:Tbc|tbc]] ([[User talk:Tbc|talk]]) 12:34, 29 July 2015 (UTC)''

:: In Dutch: "Het was nacht, stikdonkere nacht. Veertig rovers zaten rond een vuur. De roverhoofdman stond op een zei: "Het was nacht, stikdonkere nacht... " "
:: Which translates to something along the lines of: "It was night, a pitchblack night. 40 robbers sat round a fire, their leader stood up and said: "It was night, a pitchblack night..." "
:: Sometimes the fire is replaced by the shadow of a dandelion. "..Forty robbers sat in the shadow of a Dandelion, their Chief stood up and said: "It was a dark night, forty robbers sat in the shadow of a dandelion", etc. -- [[Special:Contributions/141.101.104.67|141.101.104.67]] 13:01, 29 July 2015 (UTC)

Note that the recursion doesn't necessary be infinite. The list of travelers who met each other can have fixed length, for example 10. Imagining that the list is infinite is the joke. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 10:06, 29 July 2015 (UTC)

Should we mention {{w|quines}}, which occur when lists like this end after two iterations, as "Yo, I'm MC Quine and I'm here to say/'Yo, I'm MC Quine and I'm here to say'!" {{unsigned|FourViolas}}

This reminds me of Theodor Storm's "Schimmelreiter" ([https://en.wikipedia.org/wiki/The_Rider_on_the_White_Horse "The Rider on the White Horse"]) which descends through three nested levels of narrators before it comes to the real story. --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 13:56, 29 July 2015 (UTC)

Talk:1292: Pi vs. Tau

2013-11-18T15:15:32Z

Ulm: 4.71238898038469 converted to octal

I started an explanation. Hopefully others will help improve it, as I don't think it's quite adequate. [[Special:Contributions/199.27.130.174|199.27.130.174]] 05:32, 18 November 2013 (UTC)

The comic currently shows the symbol π (pi) in all three cases, but it should have the symbol τ (tau) in the rightmost case. I'm sure there is a compromise symbol "pau" too. Maybe with a deformed left leg? [[Special:Contributions/141.101.97.4|141.101.97.4]] 07:07, 18 November 2013 (UTC)

WolframAlpha gives
<pre>
4.5545743763144164456766617143366171162404440766665105335330776311513504520604364524762740226212061363100001776216741750712622557020442741544760057441760026766230424023460366047331305225241275347777145543054127636365666430221066167347236617261603127725745513663702031155234027041040155322217227723576660045156156303357534162372112340027743775672417274565277274565735325624457113522164166560115654407251403563246444122664066521461311773474046032763760765740133706761276420415672577471077133607673035331070364705651055376634161405567176532346433567731715723623721267302576735154761375545411215522177775706407470673020025353246535120744232706060324711633457720155013202527060250466252665661576165164140301645132275526153126363575631176312270212441433434206352313125326760006365710744276056412434626534152021052065172556442150110056601034116570607064550553636566432544260105637423220411372664024454234201642615033200331506013362432026775605543212342336511350621361642654426372425415023071413764173735461042064323757413414533013..._8</pre> which does indeed have four 666 sequences. [[Special:Contributions/141.101.99.254|141.101.99.254]] 08:06, 18 November 2013 (UTC)
This number contains 7777, 000 and 444 twice, though. [[Special:Contributions/141.101.93.11|141.101.93.11]] 09:08, 18 November 2013 (UTC)

Wrote the transcript, not sure if I explained the visual well enough, so I left the incomplete tag if someone else has a better idea. Should suffice for understanding however, considering the content [[Special:Contributions/108.162.248.18|108.162.248.18]] 08:55, 18 November 2013 (UTC)

----

(The discussion about different results was trimmed)

Wolfram gives the result with 666

http://www.wolframalpha.com/input/?i=1.5+pi+octal
<pre>
4.554574376314416445676661714336617116240444076666510533533077631151350452060436452476274022621206136310000177621674175071262255702044274154476005744176002676623042402346036604733130522524127534777714554305412763636566643022
</pre>
The Unix arbitrary precision calculator gives the result without

$ echo "scale=200; obase=8; 6*a(1)" | bc -l
<pre>
4.554574376314416443236234514475050122425471573015650314763354527003043167712611655054674757031331252340351471657646433317273112431020107644727072362457372164022043765215506554422014311615574251563446213636251744101107770257
</pre>
Any suggestions how we can check them?

"Randall says so" is probably correct, but insufficient :-) {{unsigned|Mike}}

:Please use the <nowiki><pre></nowiki> tag for this long numbers.--[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 09:20, 18 November 2013 (UTC)

Testing Wolfram Alpha with <pre>4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8 in decimal</pre> and <pre>4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000_8 in decimal</pre> both indicate the approximation is only accurate to a limited degree.
http://www.wolframalpha.com/input/?i=4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8+in+decimal
http://www.wolframalpha.com/input/?i=4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8+in+decimal

The method I used to get the value I put in the text was; I used the following command to generate my approximation:
<pre>echo 'scale=200; obase=8; a(1) * 6' | bc -l | tr -d ' \\\n' ; echo</pre> which outputs<pre>
4.554574376314416443236234514475050122425471573015650314763354527003043167712611655054674757031331252340351471657646433317273112431020107644727072362457372164022043765215506554422014311615574251563446213636251744101107770257
</pre>
In 'bc'', a(1) is arctangent of 1 (i.e. 45 degrees, or pi/4); (pi/4 * 6) should be equal to 'pau'. I additionally checked the result using base 2 encoding, and converted each three bit binary value into an octal value. The decimal value of pi (using a(1) * 4) matches with the value of pi to at lease 1000 digits.
[[Special:Contributions/173.245.54.86|173.245.54.86]] 09:21, 18 November 2013 (UTC)

Both Maxima and the GNU Emacs calculator output as the first 1000 octal digits:
<pre>
4.5545743763144164432362345144750501224254715730156503147633545270030431677126116550546747570313312523403514716576464333172731124310201076447270723624573721640220437652155065544220143116155742515634462136362517441011077702611156024117447125224176203716336742057353303216470257662666744627534325504334506002730517102547504145216661211250027531716641276765735563341721214013553453654106045245066401141437740626707757305450703606440651111775270032710035521352101513622062164457304326450524432531652666626042202562202550566425643040556365710250031642467447605663240661743600041052212627767073277600402572027316222345356036301002572541750000114422036312122341474267232761775450071652613627306745074150251171507720277250030270442257106542456441722455345340370205646442156334125564557520336340223313312556634450170626417234376702443117031135045420165467426237454754566012204316130023063506430063362203021262434464410604275224606523356702572610031171344411766505734615256121034660773306140032365326415773227551
</pre>
This also agrees with the first 220 digits of the previous result (last two digits above are 57 vs 61 here, maybe due to rounding when converting to octal). Again, no 666 within the first 200 digits. The Wolfram result deviates from this at the 18th digit already. --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 10:21, 18 November 2013 (UTC)

Also e+2 does not contain the substring '666':
<pre>echo "scale=200; obase=8; e(1) + 2" | bc -l</pre>
<pre>4.55760521305053551246527734254200471723636166134705407470551551265170233101050620637674622347347044466373713722774330661414353543664033100253542141365517370755272577262541110317650765740633550205306625</pre>--[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 10:43, 18 November 2013 (UTC)

: A sudden flash of realization: are we getting nerd-sniped here?--[[Special:Contributions/108.162.254.168|108.162.254.168]] 11:55, 18 November 2013 (UTC)

: The claim is clearly about e+2, making Dgbrt's comment closest to the right direction. [[Special:Contributions/173.245.54.40|173.245.54.40]] 12:03, 18 November 2013 (UTC)

When I take Wolfram alpha's octal(pi*1.5) I get the first 303 (base 10) characters as this:
<pre>
4.554574376314416445676661714336617116240444076666510533533077631151350452060436452476274022621206136310000177621674175071262255702044274154476005744176002676623042402346036604733130522524127534777714554305412763636566643022106616734723661726160312772574551366370203115523402704104015532221722772357666
</pre>
200(base 10) is 310(base 8) so in the fist '200' characters, 666 shows up 4 times (5 if you count 6666 as twice?) [[User:Xami|Xami]] ([[User talk:Xami|talk]]) 14:01, 18 November 2013 (UTC)

: The Wolfram result is what you get when you calculate pi*3/2 in decimal, round to 14 digits after the decimal point and then convert to octal. That is, 4.7123889803846910 converted to octal. Definitely, this won't give you 200 digits precision. --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 15:15, 18 November 2013 (UTC)

Being τ, tau, is already being expressed in terms of π, pi, it shows bias. (Though I think Pau would lead to some interesting spherical geometry equations. ~~Drifter

Talk:1292: Pi vs. Tau

2013-11-18T10:29:59Z

Ulm:

Talk:1292: Pi vs. Tau

2013-11-18T10:21:30Z

Ulm: Maxima

I started an explanation. Hopefully others will help improve it, as I don't think it's quite adequate. [[Special:Contributions/199.27.130.174|199.27.130.174]] 05:32, 18 November 2013 (UTC)

The comic currently shows the symbol π (pi) in all three cases, but it should have the symbol τ (tau) in the rightmost case. I'm sure there is a compromise symbol "pau" too. Maybe with a deformed left leg? [[Special:Contributions/141.101.97.4|141.101.97.4]] 07:07, 18 November 2013 (UTC)

WolframAlpha gives
<pre>
4.5545743763144164456766617143366171162404440766665105335330776311513504520604364524762740226212061363100001776216741750712622557020442741544760057441760026766230424023460366047331305225241275347777145543054127636365666430221066167347236617261603127725745513663702031155234027041040155322217227723576660045156156303357534162372112340027743775672417274565277274565735325624457113522164166560115654407251403563246444122664066521461311773474046032763760765740133706761276420415672577471077133607673035331070364705651055376634161405567176532346433567731715723623721267302576735154761375545411215522177775706407470673020025353246535120744232706060324711633457720155013202527060250466252665661576165164140301645132275526153126363575631176312270212441433434206352313125326760006365710744276056412434626534152021052065172556442150110056601034116570607064550553636566432544260105637423220411372664024454234201642615033200331506013362432026775605543212342336511350621361642654426372425415023071413764173735461042064323757413414533013..._8</pre> which does indeed have four 666 sequences. [[Special:Contributions/141.101.99.254|141.101.99.254]] 08:06, 18 November 2013 (UTC)
This number contains 7777, 000 and 444 twice, though. [[Special:Contributions/141.101.93.11|141.101.93.11]] 09:08, 18 November 2013 (UTC)

Wrote the transcript, not sure if I explained the visual well enough, so I left the incomplete tag if someone else has a better idea. Should suffice for understanding however, considering the content [[Special:Contributions/108.162.248.18|108.162.248.18]] 08:55, 18 November 2013 (UTC)

----

(The discussion about different results was trimmed)

Wolfram gives the result with 666

http://www.wolframalpha.com/input/?i=1.5+pi+octal
<pre>
4.554574376314416445676661714336617116240444076666510533533077631151350452060436452476274022621206136310000177621674175071262255702044274154476005744176002676623042402346036604733130522524127534777714554305412763636566643022
</pre>
The Unix arbitrary precision calculator gives the result without

$ echo "scale=200; obase=8; 6*a(1)" | bc -l
<pre>
4.554574376314416443236234514475050122425471573015650314763354527003043167712611655054674757031331252340351471657646433317273112431020107644727072362457372164022043765215506554422014311615574251563446213636251744101107770257
</pre>
Any suggestions how we can check them?

"Randall says so" is probably correct, but insufficient :-) {{unsigned|Mike}}

:Please use the <nowiki><pre></nowiki> tag for this long numbers.--[[User:Dgbrt|Dgbrt]] ([[User talk:Dgbrt|talk]]) 09:20, 18 November 2013 (UTC)

Testing Wolfram Alpha with <pre>4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8 in decimal</pre> and <pre>4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000_8 in decimal</pre> both indicate the approximation is only accurate to a limited degree.
http://www.wolframalpha.com/input/?i=4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8+in+decimal
http://www.wolframalpha.com/input/?i=4.55457437631441644567666171433661711624044407666651053353307763115135045206043645247627402262120613631000177621674175071262255_8+in+decimal

The method I used to get the value I put in the text was; I used the following command to generate my approximation:
<pre>echo 'scale=200; obase=8; a(1) * 6' | bc -l | tr -d ' \\\n' ; echo</pre> which outputs<pre>
4.554574376314416443236234514475050122425471573015650314763354527003043167712611655054674757031331252340351471657646433317273112431020107644727072362457372164022043765215506554422014311615574251563446213636251744101107770257
</pre>
In 'bc'', a(1) is arctangent of 1 (i.e. 45 degrees, or pi/4); (pi/4 * 6) should be equal to 'pau'. I additionally checked the result using base 2 encoding, and converted each three bit binary value into an octal value. The decimal value of pi (using a(1) * 4) matches with the value of pi to at lease 1000 digits.
[[Special:Contributions/173.245.54.86|173.245.54.86]] 09:21, 18 November 2013 (UTC)

Both Maxima and the GNU Emacs calculator output as the first 1000 octal digits:
<pre>
4.5545743763144164432362345144750501224254715730156503147633545270030431677126116550546747570313312523403514716576464333172731124310201076447270723624573721640220437652155065544220143116155742515634462136362517441011077702611156024117447125224176203716336742057353303216470257662666744627534325504334506002730517102547504145216661211250027531716641276765735563341721214013553453654106045245066401141437740626707757305450703606440651111775270032710035521352101513622062164457304326450524432531652666626042202562202550566425643040556365710250031642467447605663240661743600041052212627767073277600402572027316222345356036301002572541750000114422036312122341474267232761775450071652613627306745074150251171507720277250030270442257106542456441722455345340370205646442156334125564557520336340223313312556634450170626417234376702443117031135045420165467426237454754566012204316130023063506430063362203021262434464410604275224606523356702572610031171344411766505734615256121034660773306140032365326415773227551
</pre>
This also agrees with the first 220 digits of the previous result (last two digits above are 57 vs 61 here, maybe due to rounding when converting to octal). Again, no 666 within the first 200 digits. --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 10:21, 18 November 2013 (UTC)

Talk:1179: ISO 8601

2013-02-27T17:14:39Z

Ulm: delete duplicate signature

Apparently there are some mistakes in the Roman numerals in the comic, the year MMXII is 2012. Also LVII/CCLXV = 57/265, whereas February 27th is the 58th day of the year (which has 365 days). --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 07:55, 27 February 2013 (UTC)
:Just guessing, but could this have something to do with the divergence of various Roman calendars, e.g. Julian vs. Gregorian? [[Special:Contributions/98.122.166.235|98.122.166.235]] 13:55, 27 February 2013 (UTC)
:Another error: Obviously 1330300800 is intended to be Unix time, but it corresponds to 2012-02-27 00:00:00 UTC. --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 08:10, 27 February 2013 (UTC)
:The day part "57" is not wrong: Since Feb 27 is the 58th day of the year, at the beginning of that day, 57 days have gone by since the year started. (At the end of the day, 58 days have gone by) Since we associate days with their beginning (like we do with e.g. hours and minutes), 57 is the correct number (or else Dec 31 would be 2013+365/365 = 2014, and therefore in the wrong year) -- [[User:Xorg|Xorg]] ([[User talk:Xorg|talk]]) 13:53, 27 February 2013 (UTC)
::Meanwhile the comic was replaced, with CCLXV corrected to CCCLXV. --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) Prima vigilia, XVI Kal. Mar. MMDCCLXVI

Can anyone explain 01237 (last interpretation before the cat)? Thanks [[Special:Contributions/68.230.38.154|68.230.38.154]] 08:04, 27 February 2013 (UTC)
:The small numbers above and below the larger ones show which digit is used where. For example, the 2nd and 5th digit is a 0, the 3rd digit is a 1 etc. [[Special:Contributions/82.115.151.1|82.115.151.1]] 08:15, 27 February 2013 (UTC)
:01237 are the digits used in the date, and the numbers above and below them reflect the order in which they are written; 0 is the second and fifth digit, 1 is the third digit, 2 is the first, sixth and seventh digit, 3 is the fourth digit, and 7 is the eighth digit: 20130227 [[User:Bdemirci|Bdemirci]] ([[User talk:Bdemirci|talk]]) 08:15, 27 February 2013 (UTC)

Someone can explain me what means: ((3+3)×(111+1)-1)×3/3-1/33? {{unsigned|95.23.147.48}}
:Read the comic explanation. '''[[User:Davidy22|Davidy²²]]'''[[User talk:Davidy22|<tt>[talk]</tt>]] 10:58, 27 February 2013 (UTC)

A strange thing is that he forgot the form mostly used in Europe: 27.01.2013. --[[User:DaB.|DaB.]] ([[User talk:DaB.|talk]]) 12:44, 27 February 2013 (UTC)
:: That form is mostly used in Germany. Belgium and France use 27/01/2013 more, Netherlands use 27-01-2013. No idea what the UK prefers although I could imagine 01.27.2013.[[Special:Contributions/62.159.14.62|62.159.14.62]] 12:58, 27 February 2013 (UTC)
::: The UK prefers 27/02/2013 --[[User:H|H]] ([[User talk:H|talk]]) 13:20, 27 February 2013 (UTC)
::: That form (27.02.2013) is also common in all of Scandinavia. --[[User:Buggz|Buggz]] ([[User talk:Buggz|talk]]) 14:15, 27 February 2013 (UTC)

The image text has a subtle twist as "12/01/04" offers no contextual clues to it meaning at all, can be read three different ways : "December 1st 2004", "January 12, 2004" or "January 4th, 2012" (as opposed to, for example, "01/15/98" which could only be interrupted as "January 15th, 1998") [[User:JamesCurran|JamesCurran]] ([[User talk:JamesCurran|talk]]) 14:29, 27 February 2013 (UTC)
: Technically speaking, it could also be interpreted as April 1st 2012 or April 12th 2001, though that would be the least likely interpretation. I personally like spelling out 3 letters of the month and using an apostrophe before the year, such as 27 Feb '13. --[[User:Joehammer79|Joehammer79]] ([[User talk:Joehammer79|talk]]) 15:07, 27 February 2013 (UTC)

Is there any way to convert the time-stamp placed on these comments to the YYYY-MM-DD format? --16:17, 27 February 2013 (UTC)

Talk:1179: ISO 8601

2013-02-27T17:13:40Z

Ulm: CCLXV was corrected

Apparently there are some mistakes in the Roman numerals in the comic, the year MMXII is 2012. Also LVII/CCLXV = 57/265, whereas February 27th is the 58th day of the year (which has 365 days). --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 07:55, 27 February 2013 (UTC)
:Just guessing, but could this have something to do with the divergence of various Roman calendars, e.g. Julian vs. Gregorian? [[Special:Contributions/98.122.166.235|98.122.166.235]] 13:55, 27 February 2013 (UTC)
:Another error: Obviously 1330300800 is intended to be Unix time, but it corresponds to 2012-02-27 00:00:00 UTC. --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 08:10, 27 February 2013 (UTC)
:The day part "57" is not wrong: Since Feb 27 is the 58th day of the year, at the beginning of that day, 57 days have gone by since the year started. (At the end of the day, 58 days have gone by) Since we associate days with their beginning (like we do with e.g. hours and minutes), 57 is the correct number (or else Dec 31 would be 2013+365/365 = 2014, and therefore in the wrong year) -- [[User:Xorg|Xorg]] ([[User talk:Xorg|talk]]) 13:53, 27 February 2013 (UTC)
::Meanwhile the comic was replaced, with CCLXV corrected to CCCLXV. --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) Prima vigilia, XVI Kal. Mar. MMDCCLXVI --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 17:13, 27 February 2013 (UTC)

Can anyone explain 01237 (last interpretation before the cat)? Thanks [[Special:Contributions/68.230.38.154|68.230.38.154]] 08:04, 27 February 2013 (UTC)
:The small numbers above and below the larger ones show which digit is used where. For example, the 2nd and 5th digit is a 0, the 3rd digit is a 1 etc. [[Special:Contributions/82.115.151.1|82.115.151.1]] 08:15, 27 February 2013 (UTC)
:01237 are the digits used in the date, and the numbers above and below them reflect the order in which they are written; 0 is the second and fifth digit, 1 is the third digit, 2 is the first, sixth and seventh digit, 3 is the fourth digit, and 7 is the eighth digit: 20130227 [[User:Bdemirci|Bdemirci]] ([[User talk:Bdemirci|talk]]) 08:15, 27 February 2013 (UTC)

Someone can explain me what means: ((3+3)×(111+1)-1)×3/3-1/33? {{unsigned|95.23.147.48}}
:Read the comic explanation. '''[[User:Davidy22|Davidy²²]]'''[[User talk:Davidy22|<tt>[talk]</tt>]] 10:58, 27 February 2013 (UTC)

A strange thing is that he forgot the form mostly used in Europe: 27.01.2013. --[[User:DaB.|DaB.]] ([[User talk:DaB.|talk]]) 12:44, 27 February 2013 (UTC)
:: That form is mostly used in Germany. Belgium and France use 27/01/2013 more, Netherlands use 27-01-2013. No idea what the UK prefers although I could imagine 01.27.2013.[[Special:Contributions/62.159.14.62|62.159.14.62]] 12:58, 27 February 2013 (UTC)
::: The UK prefers 27/02/2013 --[[User:H|H]] ([[User talk:H|talk]]) 13:20, 27 February 2013 (UTC)
::: That form (27.02.2013) is also common in all of Scandinavia. --[[User:Buggz|Buggz]] ([[User talk:Buggz|talk]]) 14:15, 27 February 2013 (UTC)

The image text has a subtle twist as "12/01/04" offers no contextual clues to it meaning at all, can be read three different ways : "December 1st 2004", "January 12, 2004" or "January 4th, 2012" (as opposed to, for example, "01/15/98" which could only be interrupted as "January 15th, 1998") [[User:JamesCurran|JamesCurran]] ([[User talk:JamesCurran|talk]]) 14:29, 27 February 2013 (UTC)
: Technically speaking, it could also be interpreted as April 1st 2012 or April 12th 2001, though that would be the least likely interpretation. I personally like spelling out 3 letters of the month and using an apostrophe before the year, such as 27 Feb '13. --[[User:Joehammer79|Joehammer79]] ([[User talk:Joehammer79|talk]]) 15:07, 27 February 2013 (UTC)

Is there any way to convert the time-stamp placed on these comments to the YYYY-MM-DD format? --16:17, 27 February 2013 (UTC)

Talk:1179: ISO 8601

2013-02-27T08:10:49Z

Ulm: Unix time

Talk:1179: ISO 8601

2013-02-27T08:03:06Z

Ulm:

Talk:1179: ISO 8601

2013-02-27T07:55:34Z

Ulm: MMXII

Apparently there's a mistake in the Roman numerals in the comic, the year MMXII is 2012. --[[User:Ulm|ulm]] ([[User talk:Ulm|talk]]) 07:55, 27 February 2013 (UTC)

Talk:1137: RTL

2012-11-22T12:34:48Z

Ulm: bidi_mirrored characters

There's a typo in the comic - hte should be eht for "the" spelled backwards -jars99

:Unless you consider "th" a single character, which by the way makes a lot of sense as it is derived from old-english "eth". {{unsigned|62.245.198.190}}
::Unless you further consider that "they" doesn't share that in the comic, making it internally inconsistent. [[Special:Contributions/76.122.5.96|76.122.5.96]] 11:40, 21 November 2012 (UTC)

Acutally, unicode 202e doesn't "flip proceeding text back-to-front", it overrides the direction, setting it to "right-to-left" for the following text. It's back-to-front for most of us like "left-to-right" is to other writing systems. I know it's nitpicking, but xkcd readers should appreciate the symmetry. [[User:BKA|BKA]] ([[User talk:BKA|talk]]) 07:23, 21 November 2012 (UTC)

I don't see the reversed title. My window manager is not UTF-8 compatible, so when a window title is set to string containing UTF-8 characters, it doesn't change. This brings the question if it really is a browser problem or if the browsers behave as expected and the window manager is at fault. -- [[Special:Contributions/89.177.52.2|89.177.52.2]] 09:17, 21 November 2012 (UTC)

:It's not a ''problem'' per sec. Browsers that get the reversed title are processing the UTF symbol correctly, there's no bug there. And the window manager has no bearing on the title text except for maybe font. [[User:Davidy22|Davidy22]][[User talk:Davidy22|<tt>(talk)</tt>]] 09:32, 21 November 2012 (UTC)

::Well its the window manager that renders the window title, but it is composed by the Browser. I think that the browser should insert an appropriate number of U+202c characters, in this case it should be "xkcd: [U+202e]LTR[U+202c] - Mozilla Firefox". That would render as xkcd: RTL - Mozilla Firefox". By the way, the tab caption in Firefox is "xkcd: LTR". In Chromium and Opera it is shown correctly as "xkcd: RTL". [[User:Joha.ma|Joha.ma]] ([[User talk:Joha.ma|talk]]) 09:47, 21 November 2012 (UTC)

Another way to see this in effect is to try to type in this test page: http://www.fileformat.info/info/unicode/char/202e/browsertest.htm - and this also works in etherpad, as suggested in the caption.--[[User:Anarcat|Anarcat]] ([[User talk:Anarcat|talk]]) 00:09, 22 November 2012 (UTC)

Black Hat seems to have used U+202b, not e. The individual characters are left-to-right. Check the D, E, L, N, S, and ? [[Special:Contributions/24.193.153.138|24.193.153.138]] 02:46, 22 November 2012 (UTC)
:No, U+202e does not actually mirror the characters themselves, just the displayed order. U+202b only changes the order for characters that don't have embedded direction, such as the period, which can be used with multiple languages. [[User:Bugefun|Bugefun]] ([[User talk:Bugefun|talk]]) 05:00, 22 November 2012 (UTC)
::Actually, it does mirror some characters, namely those that have the ''mirrored'' property. For example, the parentheses or mathematical relations like the less-than sign. [http://www.unicode.org/Public/UNIDATA/BidiMirroring.txt Here] is a list of them. --[[User:Ulm|Ulm]] ([[User talk:Ulm|talk]]) 12:34, 22 November 2012 (UTC)