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

Re: HTTP/2 Header Encoding Status Update

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 04 Mar 2013 14:21:09 +0000
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
cc: ietf-http-wg@w3.org
Message-ID: <25456.1362406869@critter.freebsd.dk>
Content-Type: text/plain; charset=ISO-8859-1
--------
In message <loom.20130304T122610-306@post.gmane.org>, 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
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 4 March 2013 14:21:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 4 March 2013 14:21:35 GMT