W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: HTTP/2 Header Encoding Status Update

From: James Cloos <cloos@jhcloos.com>
Date: Wed, 27 Feb 2013 20:24:42 -0500
To: ietf-http-wg <ietf-http-wg@w3.org>
Cc: James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>
Message-ID: <m3fw0h9qmk.fsf@carbon.jhcloos.org>
>>>>> "JMS" == James M Snell <jasnell@gmail.com> writes:

JMS> Not much really... assuming we're representing the value as a 64-bit
JMS> long, the maximum number of uvarint bytes we can ever encode for each
JMS> date is 10. Using the original epoch, I think we use six bytes
JMS> currently. The new epoch uses five. As it is, the use of the uvarint
JMS> gives us plenty of room to grow with or without the new epoch so I'd
JMS> be perfectly fine without that detail.

A quick test reminds one that the tick before 1990/01/01 00:00:00 UTC was
1989/12/31 23:59:60 UTC, a leap second.  So the reference will differ
depending on right vs posix localtime rules and be extra ambiguous because
it is just after a leap second.

  :; TZ=posix/UTC perl -e 'print localtime(631152000)."\n"'
  Mon Jan  1 00:00:00 1990

  :; TZ=right/UTC perl -e 'print localtime(631152015)."\n"'
  Mon Jan  1 00:00:00 1990

It probably would be better to define a specific offset from time_t 0 or
a specific offset from the GPS epoch.  Or even better define time zero
to be a specific 128-bit ntp time.

But it would be easier to use either time_t or an ntp timestamp directly.

James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
Received on Thursday, 28 February 2013 01:38:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC