Re[2]: FYI... Binary Optimized Header Encoding for SPDY

------ Original Message ------
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
>In message <emc1f2400c-3d0f-48eb-8eea-cb91edab99b3@bombed>, "Adrien W. de Croy"
>writes:
>
>
>>
>>02 = datetime (possibly just 64 bit ns since epoch)
>>
>
>
>No, no, no, no!
>
>If if you want fractional seconds in binary representation, you make
>it fractional seconds in binary representation:
>
> 32.32 bits since epoch.
>
>(or if you prefer: 64 bit count of 1/2^32 seconds since epoch)
>
>(See also: NTP)
>
>Your suggested format would pointlessly require a 64bit division
>and mulitiply operation to pull out the integer seconds field, or
>to turn a integer second field into your format.
>
I guess the point I was trying to make is maybe we should consider 
value types other than only 32 bit integers.

Best representation of date / time depends on what it will be used for 
in the end.  Any sort of epoch-based representation requires a bunch of 
divisions to convert to human-readable form, whereas epoch-based is 
obviously better for comparisons.

So maybe even several date/time types would be appropriate (I can hear 
the groans).  But that seems way OTT.

In the end though, when I get a file attributes from windows, the 
filetime members are in 64 bit ns since epoch.  So either I'd convert 
to something before transmission, or push that task through to the 
client side.

I'd have a bunch of 64 bit division to do to convert that to 32.32 or 
whatever other format.

I don't know what sort of timestamps unix serves up.  I'd expect it 
mainly to be determined by underlying clock hardware on motherboards.  

Adrien

>
>
>With a true binary format, it is just a matter of pulling 32 bits
>in/out of 64 bits.
>
>Should we later need higher resolution, a true binary format can
>trivially be extended to 48.48 bits since epoch (or 37.41 bits
>if aliens take over our computer architecture) without costing
>an expensive conversion routine.
>
>Mixed radix, and alien-radix representations of time is _always_
>wrong, no matter who blesses the format (see timeval, timespec and
>many other mistakes.)
>
>
>In reality, it is dubious if we need more than millisecond resolution
>for HTTP timestamps any time soon, and therefore the best current
>compromise format would probably be 48.16.
>
>(64 bit count of 1/65536ths of a second)
>
>--
>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 Thursday, 2 August 2012 12:10:09 UTC