Time represented as float?

[pnathan]

Per ISO8601.mli

    (** {2 Date parsing}

        [date], [time] and [datetime] parse a [string] and return the
        corresponding timestamp (as [float]).

        Times are {b always} converted to UTC representation.

        For each of these functions, a [_lex] suffixed function read
        from a [Lexing.lexbuf] instead of a [string].

        [datetime] functions also take an optional boolean [reqtime]
        indicating if parsing must fail if a date is given and not
        a complete datetime. (Default is true).

        Functions with [_tz] in their name return a [float * float option]
        representing [timestamp * offset option (timezone)]. [timestamp]
        will be the UTC time, and [offset option] is just an information
        about the original timezone. 
     *)

Why are timestamps represented as floats? Shouldn't there be an integer triple at the least for all of these(epoch in seconds, epoch fractions of second, and timezone)? Floats have losses of precision. A key use of ISO8601 is to allow locale-aware representation as opposed to epochs (which doesn't).

I would propose revising the interface to, rather than returning a float * float, returning one of these:

type instant = OffsetInstant of int * int * int | Instant of int * int

This would allow a precise buildup around the type. I am almost tempted to think, however, that this would be a better representation:

class cinstant (epoch: int) (fractional: int) (offset: int) = object(self) end

since frequently the use of methods on instants is handy (e.g., subtraction, parsing, extracting specific information) ; a direct modeling would be handy.

thoughts? I am OK submitting a PR here, I think.

[sagotch]

I'll try to look at it during the end of the week.

Probably that I did not need that much precision while writing this lib.

Also, keeping it very simple to use is important to me. I'll give you a more complete answer later, I have no time right now.