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.
26 thoughts on “Epic Clock Clocks The Unix Epoch”
Does it have a 2038 countdown mode? That could be quite fun and would only need 9 digits :)
This has me wondering about using 31 LEDs (maybe another for overflow).
What about leap seconds?
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.
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!
Thank you, Art.
Fairly capable article title you got there.
Stole it from The Register
They could add “unique” to complement “UN*X”
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!
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.
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)
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.
Sort of like “gluten-free coffee”.
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.
The case looks very nice, indeed. Unfortunately there are no images or further informations about the casing.
It’s some scraps of spotted gum laminated together in sections with a cavity cut out for the circuit boards and a recess routed for the plywood rear panel. I just made it up on the fly so no dimensions recorded.
Why is it limited at 2^31 -1 from epoch? This display can easily go to all 9s, and unix timestamps can easily be extended to 64 bits without breaking the standard.
In the code the “epoch” variable is an un-signed 32-bit integer, so it is actually limited to 2^32-1 seconds. I think that’ll last me long enough.
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.
So it takes the human-readable GPS time and turns it into the useless (to humans) Unix time.
Data in, garbage out.
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.
Yep! Though, by default, it boots into a mode that displays date/time in ISO-8601 format.
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!
Nice enclosure. How did you build it?
Please be kind and respectful to help make the comments section excellent. (Comment Policy)