Re: HTTP/2 Header Encoding Status Update

[James Cloos <[e-mail]>]

>>>>> "JMS" == James M Snell <[e-mail]> 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.

-JimC
-- 
James Cloos <[e-mail]>         OpenPGP: 1024D/ED7DAEA6