Re: [MirageOS-devel] Timestamp representation and CLOCK

[David Sheets <sheets@xxxxxxxxxxxx>]

On Thu, Jul 9, 2015 at 2:47 PM, Daniel BÃnzli
<daniel.buenzli@xxxxxxxxxxxx> 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 
> possible to get nanosecond precision timestamps and those cannot be 
> represented exactly in this representation (he also mentioned hardware not 
> having FP support as an argument).
>
> I'm now quite convinced that this should be done and would like to support 
> this both at the API level and internally in ptime (which currently only has 
> millisecond precision). I propose that the canonical representation should be 
> the following one which is basically what a POSIX timespec definition [1] 
> gives us and is OCaml 32-bit clean:
>
>   type posix_t = int64 * int
>
> Understood as a signed, second precision, time span paired with a 
> non-negative number of nano seconds ranging from 0 to 999'999'999. Formally a 
> tuple `(s, ns)` represents the time that happens at `s + 1e-9 * ns` from the 
> epoch.
>
> It also seems that there is consensus that the current CLOCK interface [2] is 
> absurd, forcing any clock source implementer to come up with calendar field 
> decomposition functions (gmtime). I think that the following interface would 
> be sufficient:
>
> 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-01-01 00:00:00 UTC. [ns] ranges
>       from [0] to [999_999_999]. *)
>
>   val current_tz_offset_s : unit -> int
>   (** [current_tz_offset_s ()] is the operating system's current local
>       time zone offset to UTC in seconds. *)
> end
>
>
> Would people agree on such an API and change for the next major release of 
> mirage ? If so, I'd be willing to actually delve into the various repos to 
> make that happen.

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. :-( If
we represent a timestamp as int * int * int, we only use word + 12
bytes, again hoping I can count. This would save some space but would
make implementations significantly more complex. Maybe there is an
even better representation?

2. What about a function on every CLOCK which tells you what precision
it can guarantee? It seems like it would be a potentially useful value
that only the CLOCK implementer knows.

David

> Best,
>
> Daniel
>
> [1] http://pubs.opengroup.org/onlinepubs/009695399/basedefs/time.h.html
> [2] 
> https://github.com/mirage/mirage/blob/04f3ed8d983f73d59ca1dd560fc9c03f99faf331/types/V1.mli#L79-L105
>
>
>
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel