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

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

Le jeudi, 25 juin 2015 Ã 18:23, Daniel BÃnzli a Ãcrit :
> * 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.
>  

I have changed things so that the library is more clear about its own limits. 
Also speaking a bit with Hannes we eventually agreed that the API would be less 
confusing if all the formats it handles are constrained by the same limits, the 
tightest of which are provided by RFC 3339 [1].  

These have the following implications:

1) There's now a precise range of floating point values that are considered 
valid timestamps. This range is available through the Ptime.{min,max} values 
that respectively represent 0000-01-01 00:00:00 UTC and 9999-12-31 23:59:59 UTC.

2) Ptime.of_posix_s now returns an option and never raises Invalid_argument. 
None is returned
if the seconds cannot be represented within the [Ptime.min;Ptime.max] range 
(and hence for NaNs and whatever inf values aswell).  

3) The Ptime.date year field is now constrained from 0000 to 9999

4) The Ptime.{add,sub}_posix_s return options whenever they exceed the range.

5) Ptime.to_* function in general no longer return options.

Updated documentation:  

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

Daniel

[1]
Thinking about this I realized that RFC 3339 is somehow conceptually ugly as 
formally it has points in time at the boundaries that you are only able to 
represent using a particular timezone offset and that you can't represent in 
UTC using the standard. For example 0000-01-01T00:00:00+00:01 would be 
-0001-12-31T23:59:00+00:00 but the latter can't match the date-time production 
(no negative year values).  

In order to simplify this I decided to only parse RFC 3339 timestamps for point 
in times that can be represented using UTC in RFC 3339 which allows to consider 
the "nice" range mentioned in 1) above.  

Also whenever I render timestamps with a given tz_offset_s argument I fall back 
to the UTC timezone if the given tz_offset_s would produce a string that 
doesn't match the date-time production.  

The devil is in the details (and at the boundaries). 

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