Hacker News new | past | comments | ask | show | jobs | submit login

I mean look... we can start getting really fun with it and get into the metrology of it all, but I'm having some fun and trying to spread the good word here.

Early programmers totally fucked up using UTC instead of TAI which as a monotonic count of seconds is a far more accurate representation of how computers keep track of time via continuous oscillation counters than any approximation of UTC until we developed widespread network synchronized NTP based systems and began to use UTC via these, and even then its not a really good representation because all these systems want to work with clean contiguous "one second is one second" time keeping, which is what monotonic time scales are, they inherently are this. So the choice of using a non-monotonic time scale on top of hardware that keeps time monotonically was flawed from the start.

We can get into the Sidereal time, Ephemeris time, the International Earth Rotation and Reference Systems Service, UT, TT, ERA, DUT1, MTC (Marian Co-ordinated Time), and what the difference is between an instance and an interval that represents a specific moment in time with an any temporal uncertainty attached... I do freely admit I'm a total unrepentant geek about this sort of thing, the only reason I don't own an atomic clock is because I just cant justify the few grand to buy one (cheapest I've seen is $1.5kAUD for an DIY module from Microsemi) when I know how precise my GPS based Stratum 0 embedded Linux NTP server is... Heck the IERS Bulletin emails are some of the only automated emails I look forward to and open up with a little glee, finding out what's up with the literal rotation of the planet, neatly dropped in my inbox!

But as nerds who already know a bunch of metrology/timekeeping stuff (which I am assuming from your comment) we could launch ourselves down the rabbit hole, and hope the readers can keep up, or as I've tried to with my comments here (particularly with the slightly whimsical choice of wordplay)... Try and give causal nerds who have only just tripped over the very idea that there is a better timescale that computers should be using instead of UTC some idea where to begin reading, and to wash away some of the false truths (like that GPS has leap seconds) and while technically TAI might not be easy for computers to use due to the retroactively corrected nature of it... at the end of the day all timekeeping is subject to measurement error, approximation, and correction either due to or in correlation with external sources, and thus because we only periodically correct computers to UTC mostly (on average) between 1hr to 1day via NTP depending on OS and preferences, correcting a monotonic system clock to the daily correlated and corrected TAI would be infinitely better due to eliminating all the leap second complaints, than repeatedly correcting the system clock to UTC and continuing to have the leap second problem, because UTC has a place in the timekeeping world a place that its miss-use by computers has now put in jeopardy (the calls driven by tech companies to fix UTC and have no more leap seconds).

Prior to the invention of NTP, system administrators would have just corrected it to TAI manually, and done so just as accurately as we would have corrected it to UTC, so arguments like "it would be harder to use TAI than UTC" have honestly never been true, its really just a problem of awareness and now that we're in a world where system firmware is broadly speaking designed to keep time via UTC and thus when you interrogate "system time" you get UTC, everything built up from this layer is "wrong" so its a bootstrapping problem on the level of switching to IPv6, yes its technically better, but none of the hardware supports it and so why bother when I can just keep hacking away at UTC/IPv4... except there's no UTC scarcity to drive any sort of adoption, so all that can be done is to proselytize the benefits of TAI to the best of ones ability and hope that eventually it makes a difference.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: