9-5 Is Out. Try the 1-6 Instead

Unix time can represent roughly from 1902 to 2038 in 32 bits. That's the usual intermediary between the clusterfork of records in zoneinfo. To convert between time zones, you convert to the simple second count of Unix time, then convert to the target zone.

Much easier to store the time as the simple count and just make the UI do the work to display it in some user-friendly fashion. When the machines communicate to each other, there is no confusion, because they do not carry any assumption baggage regarding time.

We really need to fix time representation before 2038. Julian day plus second count is a decent intermediate step to a time representation that is agnostic to the cycles and orbits of specific planets. The least disruptive end game is probably a 64-bit integer representing a simple count of the number of milliseconds elapsed since the Julian Day epoch.

That would make now about 212383579680000, and we'd have until 9223372036854775807, or about 292 million years from now, to even decide whether to go another 292 million years by making it an unsigned int, or just expand it out to 128 bits, because chip architectures have been able to handle that much for 292 million years already.

The simple count is rather easy to convert into a human readable time. Subtract an epoch constant, then modulo by some cycle-length constants. Adjust by a custom rule set if necessary.

Besides that, why would I want to call Uncle Steve in Melbourne? Why couldn't I just send an asynchronous message to him? That asynchronous message can even include metadata about when I am available for synchronous communications. So yeah, I can "publish my 'waking hours'", as summarily dismissed by that apologia for time zones. I don't know when that was written, but now that every phone can be a computer, as well as a pocketwatch and personal calendar, the built-in assumptions that were necessary beforehand are no longer required.

I don't need to know that people are typically awake in a safe range between 9 AM and 9 PM as expressed in their local time zone. I don't really even need to know when they'll be awake to pick up. I can tell the computer assistant to give their user a message, and the assistant might or might not sound an audible alert that the user has new messages. I don't even really need to publish my own waking hours. If I don't care about that aspect of my privacy, I can let my computer assistant tell other computer assistants when its user is typically receptive to synchronous communication requests, based on usage history. It can advertise my "online" status for me, or lie about it for me, such as if I tell it to say I'm "away", but I'm actually on my phone, playing a few levels of Skinnerbox 5: Revenge of the Lootbox.

Ideally, I'd never have to work with a negative date-time number, because someone always seems to want to check if t > 0 somewhere, and there's always a reason why t could plausibly be a valid negative. Or maybe someone picked some negative t as a sentinel value, and then left the company before I ever got a chance to slap them.

Julian Day is the only kind of time that has never insulted my delicate sensibilities in some way. Maybe that's intrinsic to the type, or maybe it's because those who chose to use it have never done stupid things with time (that I could see).

Throw in the rain with lack of UV in Seattle - unless you live in Wales there's not many other places that get this many consecutive days of rain and low to no UV during winter.

We're both miserable. Sounds like we should get a beverage or two and bitch about weather together. Cheers.