[MirageOS-devel] [RFC] Ptime (was Re: Unix.tm, CLOCK: date handling in MirageOS)

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

I have now settled down on an interface for Ptime and would welcome feedback 
about it. Here's the documentation:


http://erratique.ch/software/ptime/doc/Ptime

A few notes 

* Some of the names may seem verbose or long-winded. This is out of frustration 
of reading code that is confusingly quiet about the units and time scales it 
considers. I think that whenever time is handled it's better to be explicit so 
that it's easier to understand if functions are being fed with the right data.

* At the moment Ptime doesn't provide a way to access the current POSIX 
timestamp/tz_offset on your OS. This will be provided later via a Ptime_os 
module with this [1] interface through platform dependent subpackages. The 
Ptime module itself will remain free from any interaction with the OS.

* I would be glad like to get feedback on the way the library decides to handle 
leap seconds (see the basics section). The design rationale here is that by not 
having a leap second table we do handle very few edge cases in a suboptimal 
fashion and we cannot measure the number of SI seconds that occur between two 
timestamps. These cases are precisely specified and force you to program with 
that knowledge, by mostly doing nothing about it... If the library did include 
a leap seconds table we could handle these cases, however the correctness of 
the implementation would be challenged every six month by the potential 
addition or subtraction of a leap second (e.g. one is being added on the 1rst 
of july). Effectively this means that correctness depends on conditions 
external to the software itself and regaining it requires an update of the 
module and its dependent. Since in practice software tends to run for very long 
time without being updated I prefer the idea that the API impleme
 ntation 
remains correct at all points in time. Note also that the way this is handled 
is equivalent to what gmtime/mktime do.

* Regarding the preceeding point I'm tempted to remove the 
`{add,sub,diff}_posix_s` as it would reduce the problematic cases. OTOH if I 
remove them I'm almost sure that people are then going to simply use 
`to_posix_s` and add floats and come back with `of_posix_s`. At least having 
the functions in the API we can warn users in the docs that they are very 
likely trying to do something wrong. 

* Supporting POSIX timestamps representing point in time in BCE means that we 
get option results on to_date_utc_time (the well-sourced calendar calculation i 
use only work until -4800 BCE, I'll see if I can find another well-sourced 
alternative) and to_rfc3339 (which cannot represent BCE dates at all). We could 
require timestamps to start at 0001-01-01 00:00:00 UTC, while this would remove 
the options from these two functions, it would introduce one in of_posix_s (in 
which we could also put the nan case rather than raise invalid_argument). Also 
as mentioned in [2] the gmtime function of other major platforms does actually 
handle these kind of time stamps so it may be better to support them aswell. 

* The package depends on rresult at the moment but it is planned to drop that 
dependency once Pervasives.result is in. 

Best,

Daniel

[1]
http://erratique.ch/software/bos/doc/Bos_unix.OS.Time.html#VALnow_s
http://erratique.ch/software/bos/doc/Bos_unix.OS.Time.html#VALcurrent_tz_offset_s

[2]
https://github.com/mirage/mirage-clock/pull/2




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