What Time Is It? | Hacker News Reader

What Time Is It?

shkspr.mobi

31 pointsedent20 comments

> There are 11 missing days in 1752.

There aren't 11 missing days in 1752 though, there are 11 missing days in 1752 in the british calendar. As the original source notes, different countries switched to the gregorian calendar at different times, thus the "missed days" vary wildly even if you ignore Sweden (tried to switch gradually by skipping leap days, forgot to skip some, then switched back to julian, then switched to gregorian at once) and many Orthodox countries remained on Julian well into the 20th century (hence the October Revolution starting early November 1918, it was October julian) and had to skip 13 days.

Sweden is a great case. To resync after their failed attempt to switch, they included a February 30th in one year, so that is actually a valid date, in one year, in one place.

Alaska is another fun case. They switched calendars and simultaneously switched which side of the date line they were on, with the effect that Friday October 6th was followed by Friday October 18th.

One tidbit I didn't know yet, but was linked from this article: Britain wasn't actually on GMT at 1 January 1970: http://markfrimston.co.uk/articles/34/epoch-zero

To continue the thought... What about time on different planets? Our time is based on solar revolutions (mostly). If Mars had the same, their time would be different from ours very quickly.

Computers don't care much, since they will just keep using seconds since 1970, which is the same everywhere.

However, if you start regularly traveling quickly though space, the question of aligning offsets caused by relativity could get problematic.

This is already a bit of an issue. GPS satellites have to deliberately run their clocks at the "wrong" rate to cancel out the time dilation caused by their different gravitational potential.

> seconds since 1970

In UTC or TAI? (I.e., with or without leap seconds?)

unixtime is an integer, it has no concept of some seconds being different to other seconds - leap seconds only matter when converting this integer into a "human readable" format :)

> unixtime is an integer, it has no concept of some seconds being different to other seconds - leap seconds only matter when converting this integer into a "human readable" format :)

Except that's not how UNIX timestamps work (incidentally that'd be TAI time, which some non-conformant systems use for UNIX timestamps, and which DJB advocated for a few years ago, issue being TAI isn't really human-friendly).

A UNIX timestamps is UTC, it's defined as 86400 * days since epoch[0] + seconds since midnight[2]. Since UTC takes leap seconds in account, so does a unix timestamp, which in most implementations means a repeated second (and if you have sub-second timestamps, lots of repeated timestamp). Which has lead to the invention of stuff like "leap second smearing" as lots of software doesn't deal well with repeated timestamps, or more generally non-monotonic clocks.

By the by, because UNIX timestamps are now defined based on UTC and UTC didn't exist before January 1st, 1972, timestamps below +63072000 are imprecisely defined and not-entirely-specified approximations of GMT.

[1] 1970-01-01T00:00:00Z

[2] UTC

UTC.

You can use TAI as the base for your system, but it'll be non-conformant (and you'll drift out of sync with the rest of the world obviously).

...but if you use UTC, as is standard, it's not exactly "seconds since 1970", as kazagistar claimed (and as you explain in a nearby comment), which was my point.

I've seen 'sol' used to refer to the period of a solar day on Mars, which is about forty minutes longer than ours here on Earth. You still have to convert, but at least it's clear (ish?) that conversion is required without having to look at the context.

But what do you use when you have robots on both Mars and Venus?

Mathematicians.

I was about to mention that the DDHHMMZ format is used to stamp aviation weather reports and forecasts too, but I see the article beat me to it. :) Anyway here's the current (as of this comment) report from SFO if you're curious about what they look like:

  KSFO 301656Z 29011KT 10SM FEW008 SCT160 19/13 A3002 RMK AO2 SLP165 T01890128

You can see the timestamp in the second element. Once you learn the format it's second nature, really.

I'm no astronomer, but as to the article's closing question, I imagine there's some unambiguous solution based on the relative locations of celestial bodies. For example, supply the angle between earth -> sun -> Mars, and however other many data points are needed. With enough angles, I think this would also establish location, due to the propagation velocity of information.

Calendar time, when it is done truly right, is a complicated topic. There's a nice book that has way more detail on this than most people actually would want (Calendrical Calculations, https://www.amazon.com/Calendrical-Calculations-Nachum-Dersh...).

Ooh, that book looks great. Thanks, will add it to the post.

It hasn't even been 100 years since US congress had the standard time act of 1918. Visiting Golden Spike NP taught me the railroads created standard time from a good exhibit at the park's museum. In 1883 if I recall. Until then time in town A did not need to be the same as time in town AA.

But my favorite answer still is, "Time to get a watch."

The article could have been better citing RFC 2550 "Y10K and Beyond" which despite being a joke (April 1st) RFC provides a completely universal date format (can describe any date present and future, with as much precision as you want), that are orderable by their lexical sort order.

Yet present day time representation are easily parsed by regular humans.

Reply on news.ycombinator.com