64bit time_t

Chad Giffin <typosity@hotmail.com> Sat, 21 June 2008 18:38 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id AE5DC3A6868; Sat, 21 Jun 2008 11:38:08 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2322B3A6868 for <ietf@core3.amsl.com>; Sat, 21 Jun 2008 11:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6zoGVXMgMgVZ for <ietf@core3.amsl.com>; Sat, 21 Jun 2008 11:38:06 -0700 (PDT)
Received: from blu0-omc2-s20.blu0.hotmail.com (blu0-omc2-s20.blu0.hotmail.com []) by core3.amsl.com (Postfix) with ESMTP id 460343A67AC for <ietf@ietf.org>; Sat, 21 Jun 2008 11:38:06 -0700 (PDT)
Received: from BLU120-W24 ([]) by blu0-omc2-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Jun 2008 11:38:06 -0700
Message-ID: <BLU120-W240BCEF0CF3ACCC84DFBF3CAA40@phx.gbl>
X-Originating-IP: []
From: Chad Giffin <typosity@hotmail.com>
To: IETF <ietf@ietf.org>
Subject: 64bit time_t
Date: Sat, 21 Jun 2008 14:38:06 -0400
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 21 Jun 2008 18:38:06.0320 (UTC) FILETIME=[F213CF00:01C8D3CD]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I know this is not the proper forum for this message.  I lack sufficient contacts to send this idea to.  So I provide it to you here.  There are /so/ many people (influential and otherwise) on this list that seeding this proposal here seems like the best way to do it.  I apologize now if you feel I am abusing the IETF mailing list.

We currently (normally) store time as the number of elapsed seconds since January 1st 1970 GMT.  The resolution of time_t is poor.  Given the high speed applications we use today, timing based on time_t is next to impossible.

I have a solution.

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.

This method would make it EASY to make a clock chip.   It need only operate at a clock pulse rate of 8192 cycles per second (2^13.)

With 2^50 seconds storage you can date documents, artifacts and files (forward and backward, thanks to the sign bit) up to ~35,628,841 years.

Of course the significand (the 50 bits) need not be this wide.  We could shorten it and add the bits not used to the fractional part of time_t to increase resolution.

What do you think?


Chad Christopher Giffin
a.k.a. "typo"


IETF mailing list