There are seven time zones in Indiana in the tz database[1] - this doesn't count the two most used ones America/Chicago and America/New_York there's also a Kentucky tz that slightly spills into the state. Whenever anyone makes any comment about dates and times being easy to compute I just mention that yes, there are seven time zones in Indiana. Now the actual issues tend to arise when software makes assumptions like "every second will actually occur", "each second only happens once", "every minute has 60 seconds", "every day has 86400 seconds" amongst a plethora of other bad assumptions... but those are a lot more complicated to explain. I like leaning on Indiana.

1. https://en.wikipedia.org/wiki/Time_in_Indiana#tz_database

A great collection of those "every minute has 60 seconds" assumptions and why they are incorrect:

https://yourcalendricalfallacyis.com/

I just want to specify International Atomic Time, relative to some universally-agreed-upon epoch, in nanosecond units.

So without leap seconds/days, how does one keep their clocks in sync with reality?

One realises that one’s time is relative anyway and any universal time is just one’s own will to join a collective agreement that one doesn’t have to abide by. Then one puts this notion aside and prefers not to worry oneself with such things.

Uh. No. In the northern hemisphere, winter is January for centuries and centuries. Almanacs that farmers use also agree with that, so we have food to eat. Reality is much more than just rich first-world comforts. The world is deadly, and we use calendars and time-keeping as a basic survival skill. So basic, you probably don’t even realize it’s there.

There's a difference here between time as a fundamental property of the universe, and "time", which is how we relate a bunch of physical phenomenon to that fundamental force.

That's the primary driver for complexity here. Time as a property is hard to deal with because we take something simple, like how many seconds have passed since some other point in time, and then we have to correlate it to the sun and the moon and how close the Earth is to the sun and what side of the Earth we're on, and etc.

It forces computers to wrap a simple understanding of the passage of time in a lot of context that makes no difference to the computer.

Getting rid of calendaring doesn't imply that no one knows when winter is; winter is still a function of time. It's a pretty simple algorithm to figure out whether a given month is winter or not. It's easy to derive that context from an absolute measurement of time. It's an incredible amount more difficult to go from our calendaring system to any kind of absolute time, because our calendaring is kind of arbitrarily made up to keep things in sync. It bears little semblance to the passage of time, because it's purpose is more about maintaining context (i.e. the sun rises early in the morning, it's winter in January, etc) than actually measuring the passage of time.

I take it you don’t work remotely with a global team or been homeless? I understand your philosophy and largely agree with it. However reality is much more nuanced.

> because how hard can it be to work with dates?

Man they are so hard that you could go on for hours about it.

https://www.codingblocks.net/podcast/why-date-ing-is-hard/

> because how hard can it be to work with dates?

Oh man, tell me about it. Timezones are the worst. No wonder so many people just give up and use Moment.js.

I've been bit by bugs when coming to moment.js from other languages. It's the only datetime library I knew of, before you'll tell me about all the others, that mutates the datetime object when you do arithmetic.

Use UTC UNIX timestamps (i.e. Date.now()) for ALL time-related processing and only convert to hours/minutes when taking input/output from the user.

That's a good starting point, and certainly good advice for marking current time and past times. But keep in mind that future event absolute UTC can change due to politics, e.g. a change in daylight savings rules, which is less rare than you might imagine (https://en.m.wikipedia.org/wiki/Daylight_saving_time_by_coun...). That concert scheduled a year from now at 8pm in UTC+5 might actually end up occurring at 8pm in UTC+6.

> certainly good advice for marking current time and past times

But not too far past!

Uh oh, we’re going there again. If you’re doing anything in the future, that’s not always the correct thing to do. (Instants vs wall time etc)

I once had briefly traveled into a different time zone (so briefly that I hadn't thought about it) when I received a phone call asking to reschedule a doctor appointment. I entered the new time into my calendar. Then, I was an hour late to the appointment. My phone had adopted the timezone of the cell tower, and the calendar assumed I had meant "local time where I scheduled the appointment".

But I want my 4pm weekly meeting to always happen at 4pm, even if DST changes.

If DST changes and you live in a democracy, it's your fault. Vote against DST. If you don't get what you want unleash the wrath on your congress member, not the software.

Hmm, I think you should use TAI over UTC because UTC has leap-second corrections, Which means that the current time + X seconds might not actually be X seconds from now