Le vendredi, 10 juillet 2015 à 14:40, Justin Cormack a écrit :
> The base representation should be fast and at least support nanosecond
> precision (for eg profiling use cases),
You should not use any form of calendar time (POSIX time being one) for
profiling, these timestamp can go back in ti
On 9 July 2015 at 15:04, David Sheets wrote:
> Off the top of my head I notice two things:
>
> 1. The int64 and tuple representations make a timestamp use 2*word +
> 12 bytes if I count correctly. That is 20 bytes on a 32-bit machine
> and 28 bytes on a 64-bit machine to represent 12 bytes of data
Le vendredi, 10 juillet 2015 à 10:50, Richard Mortier a écrit :
> Not sure why it would necessarily lead to disaster
Well that seems quite evident to me:
1) We already saw enough — some still waiting to happen — clock rollovers in
the short history of computing. Time bugs can be really disastrou
On 9 July 2015 at 17:37, Daniel Bünzli wrote:
> Le jeudi, 9 juillet 2015 à 17:07, Richard Mortier a écrit :
>> Or, given this is all in-unikernel (isn't it?) how about the unikernel
>> specifies it's own epoch and range (and/or precision) at compile time?
>
> That seems like a recipe for disaster
