- From: James Cloos <cloos@jhcloos.com>
- Date: Wed, 27 Feb 2013 20:24:42 -0500
- To: ietf-http-wg <ietf-http-wg@w3.org>
- Cc: James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>
>>>>> "JMS" == James M Snell <jasnell@gmail.com> 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 <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Received on Thursday, 28 February 2013 01:38:33 UTC