Hacker News Reader

Comment by Corun | Hacker News Reader

I don't understand why you would ever use anything other than seconds/micros/millis since epoch. Basically no parsing; Efficiently storable; Simpler; Easier; Better.

Only argument I've ever heard is human readability... If you're reading these by hand so often then just write a script/tool/whatever to convert them to human readable. This is still easier since you don't have to find an acceptable ISO8601 implementation. And frankly, how often are you reading the dates manually but not as part of some log output of your program where it could convert it to human readable before logging?

This is sending dates the wrong way.

View on HN

One reason is because unix time is not actually seconds since the epoch. It doesn't include leap seconds (a leap second is added about every 1½ years). Currently unix time is about 30 or so seconds behind "Number of seconds since (unix) epoch".

Why does that matter? You can reliably calculate the missing seconds when converting it for output.

No, you can't reliably calculate it forward or backwards. To figure out the offset for dates in the past, you'd have to store the list of when leap seconds are added. This system is hardly a "just the number of seconds since epoch", but now have a arbitrary data attached. The official group that figures out leap seconds can't predict things more than 6 months in advance. How are you going to figure out in advance what's going to happen in 2 years time?

So every mail header in the world should represent:

  Date: Thu, 17 May 2012 08:36:04 -0700 (PDT)

  Date: 1337268964

because no one needs to look at mail headers and it should be the job of the user's mail reader to display it in a human readable form? I do not think it is so black and white. In the case of mail headers, the benefit of keeping the timestamps human readable outweighs the programmer cost for parsing them correctly.

"no one needs to look at mail headers and it should be the job of the user's mail reader to display it in a human readable form".

Exactly...

Who reads email headers? Maybe some server admin who's going through some backups of emails looking for something. He might even appreciate having a date format that's lexicographically ordered for his searching purposes.

Having a human readable date is like changing HTTP Content-Length to say "one million four hundred and fifty thousand and sixty four" so that when I'm reading through my raw server logs I can easily see the magnitude of the length of the responses.

I prefer epoch time for all the reasons you mentioned, but there are situations where you need something else. For example, you can't represent a holiday in epoch time (July 4th has four different start times in the lower 48), and if you need to do precise calculations epoch time is ambiguous around leap seconds.

I wish there was something simpler than 3339/8601, it really is a daunting mess of incompatible implementations and optional elements, but time is hard.

Reliability and lack of information. The problem with a "format" such as timestamps is that there is no defined parameters, especially cross language. I cannot rely that sending a timestamp in seconds will be read in seconds the other side (for example JS does not use seconds, it uses ms), there is no way to tell what one is over the other, either. I cannot look at a ms timestamp and say "This is in ms" over a second-based timestamp. It also lacks information, such as tz, and is of a fixed specificity. What happens when I want higher resolution time due to customer feedback? Go back and change the whole system to use MS over S.

ISO8601 defines its parameters within the body. I know I am parsing seconds from an ISO stamp because it is appended with an 'S'. It can support variable specificity, so I don't have to be second-accurate if it isn't needed.

Unix time (which is UTC, and expressed in seconds) does not embed a time zone, which is useful information in some contexts.

For example, with e-mail you want to know both the absolute time (so the mail client can indicate how long ago that was) and the sender's local time (important for human interaction).

Implementation wise, making the timezone explicit forces the implementer to think about it at least once and not make the mistake of writing a local time, which works while testing on systems that are on the same timezone and breaks down in the wild.

What do we do about date calculations that cross an epoch wrap?

Signed 64 bit seconds since epoch is enough.

Is the whole Internet on 64-bit time_t now? Will they all be by 2038? I'm guessing we won't know that answer until 2037...

x32 ABI, which got merged in newly released Linux 3.4, defines time_t to be 64-bit. I am starting to feel hopeful that we will be better prepared.

That's cool for Linux, going forward. Now we just have to take care of all the old mainframes and legacy system that will never get their O/S updated...

We won't know until 1901 ...

   >>> datetime.datetime.utcfromtimestamp(-2**31)
   datetime.datetime(1901, 12, 13, 20, 45, 52)

Reply on news.ycombinator.com