Re: 64bit time_t

Iljitsch van Beijnum <> Mon, 23 June 2008 19:57 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id A6B5E3A694C; Mon, 23 Jun 2008 12:57:15 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id F35BD3A694C for <>; Mon, 23 Jun 2008 12:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pn8fqCTf-VEY for <>; Mon, 23 Jun 2008 12:57:13 -0700 (PDT)
Received: from (unknown [IPv6:2001:1af8:2:5::2]) by (Postfix) with ESMTP id C43D63A6929 for <>; Mon, 23 Jun 2008 12:57:12 -0700 (PDT)
Received: from [] ( [] (may be forged)) (authenticated bits=0) by (8.13.3/8.13.3) with ESMTP id m5MHiuZ8046872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 22 Jun 2008 19:44:57 +0200 (CEST) (envelope-from
Message-Id: <>
From: Iljitsch van Beijnum <>
To: Chad Giffin <>
In-Reply-To: <BLU120-W240BCEF0CF3ACCC84DFBF3CAA40@phx.gbl>
Mime-Version: 1.0 (Apple Message framework v924)
Subject: Re: 64bit time_t
Date: Sun, 22 Jun 2008 19:45:26 +0200
References: <BLU120-W240BCEF0CF3ACCC84DFBF3CAA40@phx.gbl>
X-Mailer: Apple Mail (2.924)
Cc: IETF <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"

On 21 jun 2008, at 20:38, Chad Giffin wrote:

> Make time_t 64 bits wide.  Make the most significant bit (bit 63) a  
> sign bit.  Make the next 50 significant bits store the number of  
> seconds elapsed since January 1st 2000 GMT.  The last 13 bits be of  
> fractions of a second.

Compute time in 1/8192s of a second? That seems highly unworkable.

Also, what kind of time are we talking about? We all like to live  
under the assumption that a day is 86400 seconds long, but  
unfortunately, the definitions of "day", "86400" and "second" are such  
that this is not the case, so there are different kinds of time that  
make different kinds of compromises, like as leap seconds for UTC.

Note that leap seconds make converting between UTC and the actual  
number of seconds since any chosen epoch a non-trivial exercise for  
the present and the past, and impossible for the future without  
deviating from the definition of "second".

Last but not least, common C APIs already support microsecond  
resolution for timing, I forget the exact name, though.

> What do you think?

I think using a single value for high precision timing as well as  
calendar timing is asking for trouble. Then again, there are also  
people who think changing your clock is a good way to get up a bit  
earlier in the summer.
IETF mailing list