Re: HTTP/2 Header Encoding Status Update

["Poul-Henning Kamp" <[e-mail]>]

Content-Type: text/plain; charset=ISO-8859-1
--------
In message <[e-mail]>, Nicolas Mailhot writes:

>Also would if be possible to ask one of the IETF workgroups that worked on time
>subjects to propose a time format safe wrt leap seconds and such? 

At present there are no relevant time formats which are leap-second safe.

To my knowledge nobody is seriously working on a remedy for that,
expecting leap-seconds to be killed in the next 10 years or so.

I think trying to fix it in HTTP/2 would be ill-advised if not
downright stupid, and we should just stick with POSIX, rather than
invent yet another time-format[1].

Poul-Henning

[1] The only standardized actually used format I can point to, which
can deal correctly with leap-seconds  is the "MJD" used by astronomers.

MJD counts in days + fractional days, and therefore isolates the
impact of leap-seconds to be non-accumulative, at the cost of noon
being

	X.4999942130299418

rather than

	X.5

on days which insert leap seconds.

Using MJD, with a 32 bit fraction, we get 20 microsecond resolution.

A 16 bit day-number would give us only 9180 days, 25 years, before
roll-over, but we could instigate a different epoch to buy us some
time there.

Conversions to/from POSIX/timeval/timespec would be mostly trivial,
but not without pitfalls.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[e-mail]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.