That only matters if you care about taking leap seconds into account. If you want atomic clock time, not mushy political calendar time, then an integer number of ticks suffices.

Would you prefer if I used the article's term of "precise time"?

At any rate, it's a lot better to use precise time timestamps, as a single integer of seconds/miliseconds/vibrations of a caesium atom>, than a dumb "01/01/99" string of integers that rolls over and breaks at Y2K. (with associated fun parsing bugs)

> At any rate, it's a lot better to use precise time timestamps, as a single integer of seconds/miliseconds/vibrations of a caesium atom>

No, it is not always better. If you want to store when a contract is going to end you don't want care how many milliseconds are between now and then. You care that it happens exactly at midnight of the last day of the year. Not an hour earlier or later. Even when politicians intervene between now and then.

Wrong problem. None of what you're talking about is even remotely relevant.

If you can't establish accurate precise time, you have no ability to handle all that political crap layered on top. You're trying to solve a top-of-stack problem in the bottom-most layer.

Look at the tz database, the way in which the problem you think needs to be solved is actually handled. It implements all your mushy ever-changing political end-of-day end-of-week crap as a table of conversions to precise-time seconds.

In theory yes, in practice no. When you store a future contract end date in seconds/milliseconds/microseconds since some epoch. You will do that with tz database version x. A few year later some admin updates the tz database. Now you have to remember if you have to reencode your timestamps or not. To do that correctly, you need to store the version of the tz database that was used, translate it using that version to a "human-readable" date and translate it back to the the timestamp with the latest version of tz. If you don't do that you will experience silent data corruption.