Epic Clock Clocks The Unix Epoch

Admit it: when you first heard of the concept of the Unix Epoch, you sat down with a calculator to see when exactly 2³¹-1 seconds would be from midnight UTC on January 1, 1970. Personally, I did that math right around the time my company hired contractors to put “Y2K Suspect” stickers on every piece of equipment that looked like it might have a computer in it, so the fact that the big day would come sometime in 2038 was both comforting and terrifying.

[Forklift] is similarly entranced by the idea of the Unix Epoch and built a clock to display it, at least for the next 20 years or so. Accommodating the eventual maximum value of 2,147,483,647, plus the more practical ISO-8601 format, required a few more digits than the usual clock – sixteen to be exact. The blue seven-segment displays make an impression in the sleek wooden case, about which there is sadly no detail in the build log. But the internals are well documented, and include a GPS module and an RTC. The clock parses the NMEA time string from the satellites and syncs the RTC. There’s a brief video below of the clock in action.

We really like the look of [Forklift]’s clock, and watching the seconds count up to the eventual overflow seems like a fun way to spend the next two decades. It’s not the first Epoch clock we’ve featured, of course, but it’s pretty slick.

[wpvideo cbhcZqCS]

26 thoughts on “Epic Clock Clocks The Unix Epoch

    1. Leap Seconds are a CALENDAR function. This is simply a timing function, namely the number of seconds since Midnight UTC, January 1, 1970. So if you have leap seconds, it doesn’t have anything to do with the epoch, but it does mean that the calendar time you derive from it may change.

  1. GPS has its own rollover issues — See: http://www.npl.co.uk/science-technology/time-frequency/time/faqs/when-and-what-is-the-gps-week-rollover-problem-(faq-time)

    Since it uses a 10 bit counter, it goes from 0 to 1023, then back to 0, and so on. The last time that happened was in August 21, 1999, BEFORE Y2K! I worked a place that did GPS based landing systems and used GPS “clocks” to sync their radars. I warned them it was coming and was told “you don’t even work on that stuff, so butt out”. When it happened, we used mostly Magellan GPS receivers, and they all went into an “invalid almanac” error mode and died. They thought the almanac was bad because it failed the week number sequentiality test. All of the units had to have their firmware updated (at least those that weren’t in real ROM). It was quite a disruption, since we had radars all around the world. No one said “thanks” to me either!

  2. I recall the Y2K stuff. I got saddled with that for my company. I spent several long nights there with my dogs patching things leading up to the big night, and I was there the big night until about 3 AM just making sure everything was happy after the fact. I missed one thing, and at that point in time it was not strictly mine, the system that ran our phones voice mail was not Y2K compliant and it ran an ancient OS that did not have patches. The phone system vendor took care of that one after the fact, but that was it. Everything else came off without a hitch.

    I am retired now so I will be good and retired in 2038. Be fun to watch the kiddies scramble to prevent the end of the world!

    1. On the bright side, given the lessons from Y2K and the fact that *nix has moved to a 64bit value for time, it should not be a problem, unless you’re one of those mobs who completely refuse to spend any money or downtime to maintain a legacy system, which in that case you deserve the problems.

      1. 32 bit Linux still uses 32 bit for time_t. I also seem to remember that both openssl and libressl removed some hacky code to handle a pseudo 64 bit mode – meaning that some of the certificate end times wrap around.

        (And there are a lot of embedded systems that are powerful enough to run Linux (Just about) but won’t be 64 bit)

    2. A friend of mine worked for a network management software company back in 1999. He told me that they released a new version of their main software package that was “Y2K compliant”. He also said that the software had absolutely no date-dependence issues in it whatsoever. Still, companies that depended on the software all bought the new version anyway.

  3. That’s a very nice looking clock, especially the round edges and the light color of the wood.
    A small suggestion though, by adding a small strip of blue transparent plastic could improve the contrast during daytime.

    1. There’s a big difference between what can be done and what will be done. Yes, people will fix the code. And yet lots of machines will still be running unfixed code. The fallout remains to be seen.

    1. As mentioned by Art Mezins, above, GPS time has a shorter roll over than Unix time. It rolls over every 19 years, or so, and the next one is due next year.

      It’s broken down into 10 bit week and a number of seconds within that week. (With no leap seconds)

      Currently, it’s about cycle 1, (Not transmitted) week 995, second 306990.

      I suppose you could hazard a guess as to which day of which week from the number of seconds.

    2. So negative!

      But seriously, for people who work with computers that sync using the Unix epoch, knowing what time it is is hardly useless. When I look through logs and see that something happend at 1537532316, I have to type “date +%s” to figure out if that was today or not. If I had an epoch clock, I could just glance at the wall!

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.