5 ms·
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.
by cbhl 13y 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...)
- hausen 13y agoYeah, 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 13y agoHow does UTC not save you? There are no DLS transitions in UTC, and leap seconds are added (61 seconds in a minute).
- p4lindromica 13y agoleap seconds may also be negative, although none has been up until this point.
- A1kmm 13y agoEither 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.
- claudius 13y agoUTC 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 13y agoI may have weaseled out of the problem by using "may" instead of "will" in the new version at https://github.com/hausen/xkcd-clock 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 13y agoLeap 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.