S32 Unix Clock
da.vidbuchanan.co.uk
da.vidbuchanan.co.uk
The 2038 problem comes about because of overflow in a 32bit signed int, so the top byte (smallest clock hand in this case) effectively only has 7 bits instead of 8, when it goes above 0x7F is when the int is interpreted as negative.
The easiest 'fix', if it's even necessary, would be to make the smallest hand go all the way around in 128 ticks instead of 256. But really this micro blog post could just use an explanation of that to aid the visualization.
I've considered annotating the left side of the dial with the negative numbers also, e.g. ff (-01), etc., which would make it clearer that there's a discontinuity at 80, but it's also a lot of visual mess and on balance I prefer the cleaner look.
I hope that anyone wondering "why 0x80" will be curious enough to go read the linked wikipedia article, which goes into much more detail.
Some gauges do something like this. Tachometers often have RPM bands marked in yellow and red. And here are two pressure gauges that do it in different ways:
https://www.zoro.com/static/cms/product/large/Allpoints%20Fo...
https://www.enerpac.com/ccstore/v1/images/?source=/file/v501...
The problem is just that signed integers don't wrap at 0, they wrap at whatever their min/max point is - which, hopefully, my clock helps convey, along with the accompanying text. I think flipping it 180 degrees would make it less consistent overall. Maybe I'll add some more words to the blog post, heh
Having pondered the unix clock for a bit. it does not correspond to a day in any axis, which is fair enough, but it also means I have no real feel for whether the top or bottom should be the cycle point, I would say bottom to match other gauges.
This preserves the idea that all hands pointing to the top = midnight.
To anyone who expects to be working in IT in 15 years, here's a tip: take a long vacation for the whole January 2023, enjoy a rest and come back when most of the annoying problems are already solved.