This is one of those pieces of software engineering wisdom that only comes from experience. Try explaining to a newish dev why they shouldn't `const now = Date.now()` or whatever anywhere they want, but rather do it in one place for the lifecycle and pass it around, and they will look at you funny and think it's a waste of time. Classic case of simple vs easy. Time has the potential to complect everything it touches.

Oh yes. Any time I see code that tries to do some kind of scheduling, the first thing I ask is if they have considered using a library someone else has written. Way too many things can subtly go wrong, but new folks tend to think it should be easy, because how hard can it be to work with dates?

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

I learned this the hard way. Now I wrap interactions with system time in a container class so that, if need be, I can finely control time inside my app in unit tests and debugging.

In Haskell, getting the time is an IO operation. Because of this one tends to use the exact pattern you recommend.

It's also one of those things that actually is simple in restricted cases, then when you try to generalise it blows up badly, and it blows up like a time bomb rather than a landmine. When a time bomb explodes you don't quite know when it was triggered, but you have to deal with it then and there, learning a heck of a lot about time libs in general before you can proceed. What's a leap second, which years have a leap day, are time zones connected to places somehow, and so on. Just so you can fix your calendar that's part of a larger app.

> Classic case of simple vs easy.

Personally, I think my definition of "simple" changed over time. Much of that was influenced by the depth of my knowledge of particular paradigms, whether that be software or knowledge of the subjects I was writing code for.

Love the Rich references.

The PHP interops group recently added a Clock interface for this purpose. There were many comments along the lines of “what’s the point?”

Using the same time from the start of the whole operation doesn’t sound broadly right, I’m thinking deadlines retries expire logging

you pass around a time provider module, which you can (and should) mock in tests to ensure that nothing catastrophic happens if time drifts in ways you don't really expect.

Move the date up a layer and pass it into the code that deals with it, makes it easy to write tests for it

Not too bad testing these things with mocking libraries.