[voltagex_]

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]

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]

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]

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]

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]

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]

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

[p4lindromica]

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

[A1kmm]

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.