5 ms·

If you are talking about the date, it's documented how to parse it : > cat current | tai64nlocal

joosters 12y ago
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.
- drinchev 12y ago
  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 http://thedjbway.b0llix.net/leapsecs_update.html
  - MichaelGG 12y 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.
    - edwintorok 12y ago
      Yeah there should be a decision on that this year: http://www.ucolick.org/~sla/leapsecs/ http://www.ucolick.org/~sla/leapsecs/
- riobard 12y 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.
- simtel20 12y 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.
lazyjones 12y ago
Since we're talking about good programming here, I have to mention this: https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat

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.

drinchev 12y ago
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 http://thedjbway.b0llix.net/leapsecs_update.html
- MichaelGG 12y 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.
  - edwintorok 12y ago
    Yeah there should be a decision on that this year: http://www.ucolick.org/~sla/leapsecs/ http://www.ucolick.org/~sla/leapsecs/
riobard 12y 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.
simtel20 12y 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.

lazyjones 12y ago

Since we're talking about good programming here, I have to mention this: https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat https://en.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_cat