ocaml-community / iso8601.ml Goto Github PK

On Linux and macOS it works because gmtime will return a negative float, but on windows it will fail. See the result in #21.

That would be great to not depend on Unix at all!

also, see about salvaging tests from #5 .

I assume I'm doing something wrong here but I am baffled by this behaviour:

utop # ISO8601.Permissive.datetime_tz "2020-02-14T06:56:42Z";;
- : float * float option = (1581667002., Some 0.)

utop # ISO8601.Permissive.datetime_tz "2020-02-14T06:56:42Z" |> fst |> ISO8601.Permissive.string_of_datetime;;
- : string = "2020-02-14T07:56:42"

The time printed is shifted by one hour from the time that was parsed. How would I prevent that?

seems like this repo is relatively dead, I think it could be moved to ocaml-community (where I'd be happy to assure basic maintenance). What do you think @sagotch ?

it silences a warning on recent versions of the compiler!

I found nothing about https://en.wikipedia.org/wiki/ISO_8601#Durations ?

If you want I just wrote a function for "human readable durations", which would also be nice to have.

I struggle to understand from the documentation in the MLI how to format a timestamp using a format string that uses %Y and so on. Why are there so many pp functions defined? It would appear that you just need one that understands all the format specifiers. A small example how to create a string that contains a date according to (say) %Y%M%D would go a long way.

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.

From mktime doc:

The tm argument is interpreted in the local time zone.

From gmtime doc:

Assumes UTC (Coordinated Universal Time), also known as GMT.

Note : This bug will not be anymore when #1 will be fixed.

Normally we tend not to name libraries something like foo.ml but rather foo. Perhaps this repository (and the package) should simply be iso8601?

ISO8601 defines a "basic" format which contains none of the human-readable separators. See here, third bullet point.

I'm working on a DynamoDB client for OCaml (ocaml-dynamodb). Making an AWS client requires the ability to create an ISO8601 "basic" formatted datetime: see making HTTP requests, second bullet point of HTTP Header Contents.

If you have the bandwidth, I'd like to request a function like string_of_datetime_basic or string_of_datetime_short. Java's Joda-Time library uses "basic". If you don't have the bandwidth, I'm happy to craft a pull request.

a new release using jbuilder would be nice (to fix the cmx warning).