undefined | Better HN

0 pointsjoosters11y ago0 comments

Yes, it's the damn date. It doesn't matter how well documented it is, once you have to apply a conversion to logfiles before they can be easily read, you lose all your existing workflow. It becomes a pain to use.

I never understood djb's aversion to using human-readable dates in the log files. It's not a lot of effort for the computer to produce or to consume them, so we really should push the effort onto the computer, and not onto the user.

0 comments

5 comments · 3 top-level

drinchev11y ago· 2 in thread

Yeah djb's way suggest we use TAI time format, because it's more accurate. Anyway I haven't found this to be so big of a hassle for me. And it sounds really cool what it's doing :

> The standard timestamp used in "the djb way" is TAI, for Temps Atomique Internationale. It is an absolute measure of elapsed time based on the decay of cesium atoms, where one day is equivalent to exactly 86,400 TAI seconds.

> But the actual rotation of the Earth does not exactly conform to the TAI idea of time. In fact the Earth is slowing down a little bit, so that each physical day is minutely more than 86,400 TAI seconds.

> Our human notion of time is based on this physical day length, and is represented by the UTC timeclock. The UTC timeclock is intended to represent a clock that points exactly 12:00 noon when the Sun is directly overhead on the solstice at 0 degrees longitude.

http://thedjbway.b0llix.net/leapsecs_update.html

MichaelGG11y ago

Yes, leap seconds are an abomination and something that should only exist for odd use cases, like astronomers or something. Forcing UTC into all software and civil use is vile. Hopefully UTC will stop getting leap seconds, or we'll move to something like UTC with no further leap seconds.

edwintorok11y ago

Yeah there should be a decision on that this year: http://www.ucolick.org/~sla/leapsecs/

riobard11y ago

    1. push the effort onto the computer
    2. complexity increases
    3. more bugs

Given the number of bugs dealing with human-friendly date so far, it's not hard to predict which way djb prefers. Besides, it's just a logfile, not a calendar. The need for human-friendly date is probably overrated in this case.

simtel2011y ago

The aversion to human-readable timestamps is that he's using TAI to encode the timestamp so you don't e.g. get human-readable timestamps that have the same second twice after a leap second because the format is unambiguous in this regard.

j / k navigate · click thread line to collapse