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

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

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
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel