- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Thu, 02 Aug 2012 06:16:49 +0000
- To: "Adrien W. de Croy" <adrien@qbik.com>
- cc: "Yoav Nir" <ynir@checkpoint.com>, "Mike Belshe" <mike@belshe.com>, "James M Snell" <jasnell@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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. 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 06:17:15 UTC