Re: 64bit time_t

Iljitsch van Beijnum <> Mon, 23 June 2008 07:40 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id B438B3A694F; Mon, 23 Jun 2008 00:40:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D78423A6943 for <>; Mon, 23 Jun 2008 00:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.762
X-Spam-Status: No, score=-3.762 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_BAD_ID=2.837, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qjRUw2Yo4PFE for <>; Mon, 23 Jun 2008 00:40:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E66653A68DB for <>; Mon, 23 Jun 2008 00:40:45 -0700 (PDT)
Received: from [] (unknown [])by (Postfix) with ESMTP id 274C66FB824;Mon, 23 Jun 2008 09:40:24 +0200 (CEST)
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: Mon, 23 Jun 2008 09:40:24 +0200
References: <BLU120-W240BCEF0CF3ACCC84DFBF3CAA40@phx.gbl>
X-Mailer: Apple Mail (2.924)
X-imss-version: 2.051
X-imss-result: Passed
X-imss-scanInfo: M:B L:E SM:2
X-imss-tmaseResult: TT:1 TS:-9.4774 TC:1F TRN:31 TV:5.5.1026(15988.005)
X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0
X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000)
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