Re: [MirageOS-devel] Timestamp representation and CLOCK

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

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 I wrote was not precise 
enough, thanks for pointing this out.  

It should read (being constrained here by the fact that POSIX time seems to be 
the only source of time we can get):  

  "occuring at [d] * 86'400e12 + [ps] *POSIX* picoseconds"  

So in this sense [d] represents a number of POSIX days (each made of 86_400 
POSIX seconds [1]) which do correspond to UTC days. So this [d] does actually 
represent the number of UTC days since the epoch. Note that this CLOCK 
interface, being based on  POSIX time is not able to represent leap seconds.

> I think if you're going to have a two-part timestamp anyway it would
> be better to pick a break point with no semantics. E.g. 2^56

Given the above this would make the time calculations much less obvious and 
readable which I don't think is desirable.

Best,

Daniel

[1] 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_15

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