Le lundi, 13 juillet 2015 à 14:00, Tim Deegan a écrit :
> Ah, OK. Sorry for the noise.
Pointing out underspecified interfaces is not noise !
Thanks again,
Daniel
___
MirageOS-devel mailing list
MirageOS-devel@lists.xenproject.org
http://lists.xenpr
At 12:57 +0100 on 13 Jul (1436792231), Daniel Bünzli wrote:
> Le lundi, 13 juillet 2015 à 11:28, Tim Deegan a écrit :
> > UTC leap seconds make this confusing. I.e. 'd' is not exactly the
> > number of (UTC) days since the epoch, but it will _inevitably_ be used
> > for that, leading to glitches ar
Hi,
Sorry to butt in on a discussion half-way through, but:
At 00:01 +0100 on 12 Jul (1436659292), Daniel Bünzli wrote:
> module type CLOCK = sig
>
> val now_d_ps : unit -> int * int64
> (** [now_d_ps ()] is [(d, ps)] representing the time occuring at
> [d] * 86'400e12 + [ps] picosec
Le lundi, 13 juillet 2015 à 11:28, Tim Deegan a écrit :
> UTC leap seconds make this confusing. I.e. 'd' is not exactly the
> number of (UTC) days since the epoch, but it will _inevitably_ be used
> for that, leading to glitches around midnight.
In fact it is meant to. But the documentation string
That sounds a reasonable plan to me.
On 12 July 2015 at 00:06, Daniel Bünzli wrote:
> Le dimanche, 12 juillet 2015 à 00:01, Daniel Bünzli a écrit :
>> Here's how 32-bit clean addition gets implemented:
>>
>> let add (d0, ns0) (d1, ns1) =
>> let d = d0 + d1 in
>> let ns = Int64.add ns0 ns1 in
>> l
Le dimanche, 12 juillet 2015 à 00:01, Daniel Bünzli a écrit :
> Here's how 32-bit clean addition gets implemented:
>
> let add (d0, ns0) (d1, ns1) =
> let d = d0 + d1 in
> let ns = Int64.add ns0 ns1 in
> let ns_clamp = Int64.rem ns 86_400_000_000_000_000L in
> let d = d + Int64.compare ns ns_clam
Justin's point that would you store a large number of timestamps you'd anyway
devise your own representation achieved to convince me that using int64 * int
as initially proposed seemed to be the right representation to me: it has ample
range, nanosecond precision and we would not invent anything
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
Le jeudi, 9 juillet 2015 à 17:29, David Sheets a écrit :
> This gives 1 word for tuple, 1 word for int64 pointer, 1 word for
> int64 header, 1 word for int, 8 bytes for int64 data = 4*word + 8
> bytes = 24 bytes on 32-bit = 40 bytes on 64-bit
>
> :-( :-(
Still designing with nanosecond precisi
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 (and it would be hard to support at the
library level
On Thu, Jul 9, 2015 at 3:04 PM, David Sheets wrote:
> On Thu, Jul 9, 2015 at 2:47 PM, Daniel Bünzli
> wrote:
>> Hello,
>>
>> While working on ptime David Sheets suggested me that moving away from
>> OCaml's usual representation for POSIX timestamps, namely an OCaml float
>> representing seconds
On 9 July 2015 at 16:11, Daniel Bünzli wrote:
> Le jeudi, 9 juillet 2015 à 15:43, Richard Mortier a écrit :
>> What range and precision do we want?
>
> In ptime I arbitrarily chose to represent UTC timeline of RFC 3339 can
> represent (i.e. -01-01 00:00:00 UTC to -12-31 23:59:59 UTC). I d
Le jeudi, 9 juillet 2015 à 15:43, Richard Mortier a écrit :
> What range and precision do we want?
Btw. if people are interested in a little review on what has been done in a
variety of systems there's a list here:
http://userguide.icu-project.org/datetime/universaltimescale
Daniel
_
Le jeudi, 9 juillet 2015 à 15:43, Richard Mortier a écrit :
> What range and precision do we want?
In ptime I arbitrarily chose to represent UTC timeline of RFC 3339 can
represent (i.e. -01-01 00:00:00 UTC to -12-31 23:59:59 UTC). I don't
have a particular strong opinion about the precis
(General agreement to the various proposals :)
On 9 July 2015 at 15:04, David Sheets wrote:
>
> 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 da
On Thu, Jul 9, 2015 at 3:26 PM, Anil Madhavapeddy wrote:
>
> > On 9 Jul 2015, at 14:47, Daniel Bünzli
> wrote:
> >
> >
> > module type CLOCK = sig
> >
> > val now_s : unit -> int64 * int
> > (** [now_s ()] is [(s, ns)] the operating system's POSIX timestamp
> > for the current time unders
> On 9 Jul 2015, at 14:47, Daniel Bünzli wrote:
>
>
> module type CLOCK = sig
>
> val now_s : unit -> int64 * int
> (** [now_s ()] is [(s, ns)] the operating system's POSIX timestamp
> for the current time understood as the number of seconds [s] +
> 1e-9 * [ns] from the epoch 1970-
On Thu, Jul 9, 2015 at 2:47 PM, Daniel Bünzli
wrote:
> Hello,
>
> While working on ptime David Sheets suggested me that moving away from
> OCaml's usual representation for POSIX timestamps, namely an OCaml float
> representing seconds from the epoch, might be a good idea as it is nowadays
> pos
21 matches
Mail list logo
