Le vendredi, 26 juin 2015 à 13:49, Hannes Mehnert a écrit :
> Shouldn't the validity invariants hold by construction -- at least I'd
> prefer that it's not possible to create a date & utc_time which are
> invalid. That'd require some constructor functions and accessors for
> date and utc_time, but I'd prefer it over those valid_* functions
> which users will need to call.
It's not the goal of this library to provide an abstract type for date-time
values (this would rather be the goal of a calendar library). The goal of the
library is to provide a type for POSIX timestamps. In fact these valid_*
functions should not be called by the client, they are only here as a
convenience, they are called
by Ptime.of_{date_utc_time,date} functions which is what you should use
whenever you just parsed some calendar field and need to map them to a POSIX
timestamp. For handling date and time in programs I prefer to keep values
representing timestamps along a well defined timeline in your data structures,
rather than juggle with date * utc_time pairs.
> I also wonder since the finest granularity are seconds
No. The module says nothing about this. While the utc_time type has granularity
up to the second, that's not the case for a POSIX timestamp parsed from a RFC
3339 timestamp or created through Ptime.of_posix_s.
> Or, what is the meaning of adding .5 to a t?
Add 0.5 second.
Best,
Daniel
_______________________________________________
MirageOS-devel mailing list
[email protected]
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
