We're getting into domains where sub-second precision is pretty important. Logs, for instance; on s aystem handling thousands of messages a second, storing log entries at a resolution of one second gets . . . irritating.
I like Windows NT's system of seconds-since-1600-or-so in increments of 100 nanoseconds. That system has served me well. 100ns isn't crazy to read directly and often from a hardware register (talk to a hardware engineer about latching a rapid counter sometime...), it covers a reasonable range for humans (handles everyone currently alive, for their whole lifetimes and most events they care about) and it fits pretty well with events that occur in multiprocessor systems (I'll be saying something different if I ever work on systems with terahertz clock rates, though).
They are difficult to read for humans. Without using a computer can you tell me when this timestamp was taken? 1453383978
Ultimately that was the point of the article, but the tone of the article about how they got it right and everyone else is wrong bugged me.
My approach has been to store everything in epoch form, do all of my calculations and manipulations from there, then build tools that make converting back to a human readable representation when and where it is needed. I think the idea that you have a problem completely solved though just prevents the search for any improvements.
Skimming the article doesn't make it clear whether they've addressed this, but, if you want to add units of time of non-constant size, then you cannot just use time-stamps. For example, `(today + 1 year) - today` is longer than `(today + 2 years) - (today + 1 year)` [0], so that one can't think of them as just `(today.unix + seconds_in_year).human` and `(today.unix + 2*seconds_in_year).human`.
[0] Assuming that today + 1 year is defined to be 2017-01-21, and today + 2 years is defined to be 2018-01-21; and, if not, then one faces other problems with intuition.
Who cares how pretty the internal representation is? Only the processor sees that, you output pretty printed versions of the timestamp as you mentioned. You can even add the necessary bits to your debugger to automatically convert timestamps if necessary.
Dealing with sub-second precision isn't that hard. You just need either a second value that holds the microseconds/nanoseconds or 64 bit time that counts nanoseconds since the epoch instead of seconds.
One approach is to store numeric timestamps in UTC format. Then if you do have data stored in a different timezone you have to include the timezone with it. That is the default mode of operation for many of the standard date formats.
If you get timestamp data from a system outside of your control though you always have to make sure you know what it means. At least half the time it seems like a date without a timezone isn't UTC, but in whatever the originating timezone was but the developers didn't include a timezone offset in the data...Timezones....the bane of my existence.
That approach has limits, when DST raises its ugly head (for example, in a calendar scheduler). It's interesting that some of these systems ask you for timezones like "GMT London" - it appears to the user that they're asking for the three letter timezone, 'GMT' - which the user probably knows - but what they're really asking is the TZDB timezone location - which the user probably doesn't.
I like Windows NT's system of seconds-since-1600-or-so in increments of 100 nanoseconds. That system has served me well. 100ns isn't crazy to read directly and often from a hardware register (talk to a hardware engineer about latching a rapid counter sometime...), it covers a reasonable range for humans (handles everyone currently alive, for their whole lifetimes and most events they care about) and it fits pretty well with events that occur in multiprocessor systems (I'll be saying something different if I ever work on systems with terahertz clock rates, though).