Subject: 64bit time_t

From: Chad Giffin <[email-masked]>
Date: Sat, 21 Jun 2008 14:38:06 -0400

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?

Sincerely,

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

_________________________________________________________________

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Doug Ewell" <[email-masked]>
Date: Sat, 21 Jun 2008 12:47:03 -0600

Chad Giffin <typosity at hotmail dot com> 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.
>
> What do you think?

Write up an Internet-Draft and it won't be off-topic any more.  Just be 
sure to check for prior art first, because you're likely not the first 
person to try to solve this problem.

I would argue that if the data type has a 35 million year span, then 
setting the baseline at 2000-01-01 seems arbitrary.

--
Doug Ewell  *  Arvada, Colorado, USA  *  RFC 4645  *  UTN #14
http://www.ewellic.org
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages  ˆ

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 21 Jun 2008 12:03:39 -0700

Hi -

> From: "Chad Giffin" <[email-masked]>
> To: "IETF" <[email-masked]>
> Sent: Saturday, June 21, 2008 11:38 AM
> Subject: 64bit time_t
...
> What do you think?
...

This has been addressed before.
See ITU Rec. X.743  http://www.itu.int/rec/T-REC-X.743/en
for one solution.

Randy

---

From: John Levine <[email-masked]>
Date: 22 Jun 2008 01:25:23 -0000

>Make time_t 64 bits wide. ...

>What do you think?

The basic definition of time_t is in the ANSI/ISO C standards, which
say it's an arithmetic type but leave the details to the
implementation.  POSIX further defines it to be an integer number of
seconds since the 1970 epoch, with the implementation deciding how big
an integer it should be.

We all know that signed 32 bit versions of time_t will overflow in
2038, so modern POSIX systems are moving toward 64 bit versions.

If you want to update or change the definition of time_t, you need to
talk to WG14 which maintains the C standard, or PASC which maintains
the POSIX standards.  Neither of these groups is related to the IETF.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Tony Finch <[email-masked]>
Date: Sun, 22 Jun 2008 21:02:32 +0100

On Sat, 21 Jun 2008, Chad Giffin wrote:
>
> We currently (normally) store time as the number of elapsed seconds
> since January 1st 1970 GMT.

NTP represents time as an unsigned 32 bit integral number of seconds since
1900-01-01 00:00:00 plus 32 bits of fraction, i.e. the whole timestamp is
64 bit fixed point. This wraps a couple of years before 32 bit Unix time_t.

The TICTOC working group was recently chartered to specify highly accurate
time and frequency distribution. See
http://www.ietf.org/html.charters/tictoc-charter.html

It's not possible to specify a timestamp format that both fits in 64 bits
and has sufficient range and precision to be useful for most purposes.
FreeBSD's bintime format uses standard time_t (eventually 64 bits) plus 64
bits of fractional seconds, i.e. the whole timestamp is 128 bit fixed
point. The high precision avoids aliasing problems when representing
multi-GHz clock frequencies (e.g. CPU clocks).

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HEBRIDES BAILEY: NORTH 5 TO 7, BUT GALE 8 AT FIRST IN HEBRIDES, BACKING WEST 3
OR 4 LATER. ROUGH OR VERY ROUGH, DECREASING MODERATE LATER. SHOWERS. GOOD.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 23 Jun 2008 09:40:24 +0200

> seconds elapsed since January 1st 2000 GMT.  The last 13 bits be of  

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
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 22 Jun 2008 19:45:26 +0200