"Fixing" xkcd 1340

voltagex_ 12 years ago |

In theory, won't the time in this and the original occur more than once in different timezones? (Thus I should open up an issue to add the timezone)

cbhl 12 years ago | |

The "every second" version, while cheeky, probably is wrong during the fall when the end of DST causes an hour to be repeated every year in many jurisdictions.

(I'm not even sure UTC would save you here...)

claudius 12 years ago | | |

UTC would save you w.r.t. timezones, but it still has leap seconds and the like to adjust for nonuniformities in the earth’s rotation (around itself and the sun).

However, these jurisdictions change timezones in autumn and spring, so specifying the current timezone should work just as well as specifying UTC. 01:30:20 CEST is not repeated, nor is 01:30:20 CET.

hausen 12 years ago | | |

I may have weaseled out of the problem by using "may" instead of "will" in the new version at https://github.com/hausen/xkcd-clock .

Timekeeping enthusiasts: please clone, fork, and/or submit a pull request. You can now easily change the text to suit your needs.

mikeash 12 years ago | | |

Leap seconds don't cause timestamps to repeat, though. They're done by adding an extra second to a minute, so that instead of going between 0-59 seconds, that one minute goes from 0-60.

hausen 12 years ago | | |

Yeah, I should have printed a UNIX timestamp instead... ;)

A better workaround would be to write "Under our system that time and date may only happen at most once again!" in Cueball's speech bubble.

jsmeaton 12 years ago | | |

How does UTC not save you? There are no DLS transitions in UTC, and leap seconds are added (61 seconds in a minute).

p4lindromica 12 years ago | | |

leap seconds may also be negative, although none has been up until this point.

A1kmm 12 years ago | | |

Either way you don't get repeated UTC timestamps. A negative leap seconds means you go from 23:59:58 to 00:00:00 without passing 23:59:59, and a positive one means you go from 23:59:59 to 23:59:60 to 00:00:00.

disillusioned 12 years ago |

Can someone "fix" XKCD 1335 ("Now") so that the current time is at the 12 o'clock position?

http://xkcd.com/now/

ssafejava 12 years ago | |

Since the image is actually rebuilt server-side to reflect the current rotation of the earth, it's simple to just rotate it with CSS based on the current time:

http://jsfiddle.net/4taWt/1/

dm2 12 years ago | |

That would be very difficult without the server-side code.

Maybe someone can think of a clever way though.

Here is a way to get any time you want from it: http://imgs.xkcd.com/comics/now/20h30m.png

meandave 12 years ago | |

You inspired me :) http://meandavejustice.github.io/xkcd-now/

RodEsp 12 years ago | | |

Heya! You inspired me! http://rodesp.github.io/xkcd-now-clock/

mnw21cam 12 years ago | | |

Only one problem - both of these (rather cool) implementations show the incorrect time.

RodEsp 12 years ago | | |

Mine should show the correct time (it uses your system time), what makes you say it doesn't?

mnw21cam 12 years ago | | |

As of 15:36 UTC, the xkcd version has noon pointing at the S in "Canadian Maritimes", while yours has noon pointing at the U in "US East Coast". My browser timezone is currently GMT, and system time is accurate.

Rebelgecko 12 years ago | |

There's a few Android widgets you can get that'll do it

suchow 12 years ago |

The hover text (8000 years) should also update continuously.

ozh 12 years ago |

Thanks for the XKCD font, didn't know it. Will put this to good use :)

VikingCoder 12 years ago | |

I tried to strip it down to its minimal form:

http://jsfiddle.net/Lej6m/95/

mintplant 12 years ago |

Why does this trigger a GitHub authorization request?

theon144 12 years ago | |

It didn't for me.

jfoks 12 years ago |

This just begs for some hardware with an e-ink display for a tabletop xkcd...