Microseconds: fix and testcase for a bug

[qrilka]

Added proper zero padding for microseconds in date formatting and a testcase for the bug in parsing those microseconds

[ericbmerritt]

@qrilka note the CI build failed

[qrilka]

Formatting was fixed and parsing is buggy - I've added a testcase and proper fix needs parsing to be almost rewritten

[ericbmerritt]

@qrilka any updates on the build failure?

[qrilka]

this build failure was intended - it shows that the parsing code is broken.
I don't use erlware_commons in my projects and I don't have time to rewrite date parsing, sorry...

[ericbmerritt]

@qrilka ok. I understand now. Thanks. I will see if I can find some time to fix it.

[tsloughter]

Damn, @ericbmerritt you know what is going on here and what needs fixing?

[ericbmerritt]

No clue. I need to dig into this. Fortunately, with a good test case its doable. Thanks @qrilka

[qrilka]

@tsloughter the reported problem is that parsing works only for strings with 6(or zero) digits after the comma, the test case supplied shows it failing parsing "2012-12-12T12:12:12.123" incorrectly - not giving 123ms but 123us
and formatting of microseconds was fixed (it has a similar bug)

[erszcz]

Up!

Example:

> ec_date:tokenise("2016-08-18T09:37:29.000456Z", []).
[2016,45,8,45,18,9,58,37,58,29,46,456,90]

.000456 of a second is not 456 milliseconds, but that's how the fraction is tokenised and interpreted later. Actually, it is interpreted as microseconds. However:

> ec_date:parse("2016-08-18T09:37:29.456+0000").
{{2016,8,18},{9,37,29,456}}

.456 of a second isn't 456 microseconds, but that's how it's interpreted.
More examples - the first result is incorrect, the second causes an error:

> ec_date:parse("2016-08-18T09:37:29.1+0000").
{{2016,8,18},{9,37,29,1}}
> ec_date:parse("2016-08-18T09:37:29.000456Z").
** exception throw: {ec_date,{bad_date,"2016-08-18T09:37:29.000456Z"}}
     in function  ec_date:do_parse/3 (/private/tmp/erlware_commons/_build/default/lib/erlware_commons/src/ec_date.erl, line 106)

[tsloughter]

Still needs the tests to pass.

[maximvl]

It looks like @erszcz's commit covers this exact case

[erszcz]

#109 which is now merged was based on this commit PR - it does all that's done here and more. I think this PR can be closed now.