Unix Time reaches 1.7 billion

By way of analogy, imagine we implemented leap years by slowing our clocks to half speed on Feb 28 instead of adding a Feb 29.

You can do things like find midnight GMT by checking (t % 86400 == 0) for example.

In fact, UTC will change its leap second logic much sooner than Unix time logic, so UTC logic will be more like Unix time.

When you run "date", it asks the system for this number of seconds, then uses a database to look up what that number corresponds to in the local timezone, accounting for leap years and seconds, and spits out that value. So when (some of us) recently "fell behind", the Unix time incremented by 1 second, but that database told us that the time had decreased by an hour.

Not exactly sure how Windows does it, but I recently set up monitoring of a job that Task Scheduler runs, starting at midnight and running for 1 day, every 5 minutes. I got paged at 11:30 because the scheduler decided "1 day" is "24 hours", and it stopped running it at 11pm because of the time change, but didn't start the one for the next day.

I know cron can be confusing, but I'll take it any day over this.

Suit yourself, though.

    async function* tickSeconds() {
      while (true) {
        const m = new Date().valueOf()
        const s = Math.ceil((m + 10) / 1000)
        await new Promise((resolve, _) => {
          setTimeout(() => resolve(), s * 1000 - m)
        })
        yield s
      }
    }
    
    for await (const s of tickSeconds()) {
      console.log(s)
    }

We know this because we just changed the clocks to 2000 and things broke...badly.

I work with an electronic health records system. Recently they delivered a patch to customers because on Nov 8th 2023 around 0100 in the morning their time field internally would exceed its number of characters allowed.

This was weird to hear about nowadays but I was still not surprised.

They botched the patch and it was not a good time when it happened.

A big chunk of their older code based systems use an epoch of Mar 1,1980, another newer code chunk uses Mar 1, 1992 as their epoch. And I've been told their newest platform uses yet another epoch, or calculates times in such a way to not be concerned.

So while their patch increased the field size for the seconds counter, it has done so a few times only fixing the fields that use the epoch about to be hit, rather than all of them. In top of that, after the counter grew by a digit on Nov 8th,2023, they then realized, much to many hospital customer displeasure, that not all their code the displayed medical documentation/results, often sorted by most recent, accounted for the field size correctly, requiring two more patches last week.

Math with time is hard, and even harder to know what systems have moved forward with enough future thought to still not have these surprises sitting in wait deep in their codebase.

It's irrelevant to my point though. Just because the standard is used by 99% of people instead of 100% doesn't mean programmers should invent a new one, for the same reason they chose January 1st 1970 and not November 15th 1970 or any other day of the year. There's only one obvious choice.

Notably, the newest entry on that list is "Unix time". Just because there's already more than one entry on the list doesn't mean a small group of people should add another. That's not even "there are now 14 standards" that's just deliberately adding to the pile.

Regardless, just because the standard is not used by 100% of humanity doesn't justify programmers coming up with their own calendar instead of using the obvious choice. It's unnecessary.