I get the following error:

$ rebar compile

==> iso8601 (compile)
src/iso8601.erl:17: type tuple(_,_,_) undefined
src/iso8601.erl:224: type tuple(_,_) undefined
Compiling src/iso8601.erl failed:
ERROR: compile failed while processing /Users/oubiwann/lab/lfe/lupyter/deps/iso8601: rebar_abort

In Erlang 17.5, it compiles just fine:

$ rebar compile

==> iso8601 (compile)
Compiled src/iso8601.erl

While it does parse the sign, it is completely ignored on apply so -P1D just adds one day rather subtract it.

Would it be possible to tag a release, here and in Hex.pm?

Many thanks.

http://en.wikipedia.org/wiki/ISO_8601#Week_dates

e.g., YYYY-DDD

The spec allows calendar:datetime() | timestamp() but it's not enough since the second function clause allows S to be float()

https://github.com/erlsci/iso8601/blob/master/src/iso8601.erl#L32

format({{Y,Mo,D}, {H,Mn,S}}) when is_float(S) ->

And that's not valid for the calendar:datetime() type (where second() = 0..59)

On the readme it says:

Add it to your rebar.config deps:

{iso8601, ".*", {git, "https://github.com/erlsci/iso8601.git", {tag, "1.2.0"}}}
Or for rebar3:

{iso8601, {git, "https://github.com/erlsci/iso8601.git", {tag, "1.2.0"}}}

When the version string should be "1.2".

The spec located in the file https://github.com/erlsci/iso8601/blob/master/src/iso8601.erl#L41 is wrong. The function allows either string() or binary(), so probably it is a better option to use iodata() instead. This causes that dialyzer fails.

Right now, only rebar3 is being used on Travis CI. It would be good to make sure we're not breaking anything with rebar2 users. We can do this with Travis CI environments ...

Example: {{2012,7,6},{17,25,10.0}}

http://en.wikipedia.org/wiki/ISO_8601#Times

In particular, when running dialyzer, these warnings are generated:

   0: Unknown type calendar:hour/0
   0: Unknown type calendar:minute/0
   0: Unknown type calendar:second/0

Looking at calendar.er, it seems that only the following types are exported:

-export_type([date/0, time/0, datetime/0, datetime1970/0]).

Might have to just redefine calendar's private types in this lib ...

There have been multiple requests for erlang.mk support, including the following PRs:

• #13
• #14
• #15

The second two were closed as duplicates, and the first one was closed due to the original author moving on (there was a multi-year response lag from the maintainers). All the PRs offered something a little different, so whoever picks up this ticket may want to refer to them (and the associated comments) for insight.

I do not know erlang.mk, so we'll need to have some collaboration here :-)

Some notes from those PRs:

• we don't want to include erlang.mk in this project -- but!
• we can create a Makefile with a target that will download the latest erlang.mk when an erlang.mk target is run
• we'll need to update .travis.yml to add an environment for testing builds (and running tests) using erlang.mk on Travis

iso8601:parse("2018-03-07T14:15:59.966033Z").
{{2018,3,7},{14,15,60}}

I have this result for 1.3 tag version of this library.
I think it is wrong.

Library must ignore fractional part of the seconds.

Is there a negative or inverse of add_time?

http://en.wikipedia.org/wiki/ISO_8601#Time_intervals

I've got a project where erlang_iso8601 is a dependency (in the project's rebar.config file). When running rebar compile, only the .app.src and unit test file get compile and placed in the ./deps/iso8601/ebin directory:

$ ls -al deps/iso8601/ebin/
total 48
drwxr-xr-x   4 oubiwann  staff    136 Sep  6 15:45 .
drwxr-xr-x  10 oubiwann  staff    340 Sep  6 15:43 ..
-rw-r--r--   1 oubiwann  staff    262 Sep  6 15:45 iso8601.app
-rw-r--r--   1 oubiwann  staff  20244 Sep  6 15:45 iso8601_tests.beam

In order to compile the iso8601.beam file, I have to switch to deps/iso8601 and run rebar compile in that dir.

This will need to be a major version bump, since the time() type will have to change to accomodate microseconds.

The priv/images directory contains logos referenced in the README. The priv directory is usually used for storing data required to run the software, so the rebar tool includes content of the priv directory in a binary release (whereas the README.md itself is not included). The 3MB image (logo-large) makes the binary release file unnecessarily large, becase the logos aren't really required at run-time.

Would it be possible to store the images in some other directory e.g. doc/images? It wouldn't impact anything (I guess) and my release package would get significantly smaller.

how to parse <<"12/Jun/2017:11:38:12 +0800">>

nginx time_local format like this sizeof(“28/Sep/1970:12:00:00 +0600”), how to parse it?

iso8601:parse(<<"2012-07-03T18:49:23-0400">>).

It should return {{2012,7,3},{22,49,23}} but it returns {{2012,7,3},{14,49,23}}.

Fix it now, jerk!

....where allowed by the spec

Would you be interested in a pull request that moves CI from Travis CI to GitHub Actions, or at least adds GitHub Actions alongside Travis CI? It seems travis-ci.org will stop being useful from Dec 31 2020. I can do it, except that I think you need to create the workflow yml, first, in master, after which I can branch off of.