joel-costigliola/assertj-core-java-8 — pull request #4 by szpak (2014-04-11 21:17:45+00:00)
Title: Topic/datetime

I did an initial conversion of assertj-joda-time to the new Date and Time API from Java 8. I don't plan in the nearest future and I don't have thorough knowledge about new API and adjusted existing code, so there is a field to write new useful assertion and enhance existing (and probably fix bugs I introduced by the usage of those assertions in the real projects). Nevertheless I wanted to bring this module to life to make it easier for brave people to implement some interesting Java 8 related features in core(8) AssertJ assertions.

Some comments.

There is problem with parsing `2000-01-01` as `ZonedDateTime` and `LocalDateTime`. Default formatters assume the usage of [ISO_ZONED_DATE_TIME](http://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_ZONED_DATE_TIME) and [ISO_LOCAL_DATE_TIME](http://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html#ISO_LOCAL_DATE_TIME) which requires as minimum `2011-12-03T10:15` and `2013-10-02T10:10:10Z` respectively.
As passing date as `2011-12-03` might me sometimes useful and we discard (adjust) the zone information from `the other` date anyway one of the possible solutions could be to define a few formatters (e.g. ISO_ZONED_DATE_TIME, ISO_LOCAL_DATE_TIME, ISO_LOCAL_DATE) to try to some date from a given String. Or maybe remove the methods accepting String to avoid confusion.

Another potential issue to the fact that `[Zoned|Local]DateTime.toString()` prints only relevant [information](http://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#toString--) about date. It can be `uuuu-MM-dd'T'HH:mm` instead of `uuuu-MM-dd'T'HH:mm:ss.SSS` or `uuuu-MM-dd'T'HH:mm:ss.SSSSSSSSS`. Generally it is good, but that behavior can make failure messages less clear. I adjusted tests to the new format, but maybe we would like (as an enhancement) to provide a DateTimeRepresentation with a custom formatter to always print date with trailing zeros.

A few things with Maven configuration could be done better (like better usage of pluginManagement section), but it requires changes in parent pom, so I postponed it.

Btw, I also changed the artifactId (and also preferable a Git repository name) from `assertj-core-java-8` to `assertj-core-java8`. In `assertj-core-java-8-0.3.0-SNAPSHOT` `8` looks more like a part of the artifact version number. In `assertj-core-java8-0.3.0-SNAPSHOT` (for me) it is more readable. I think this is the last chance to make that modification - nobody is using this project/repo yet. Nevertheless if you do not agree with my arguments I can revert that commit.

Btw2, I did some PoC (like extracting value with a method reference), but I'm not sure where would be best to put it in the code base. Did you plan to make this module as extension to the original core or you consider the need to duplicate some code to write it in Java 8 fashion?

I'm looking for your feedback.