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