DateMatchers.isDay(int, Month, int) not adapted for non-zero time zones

[tnaskali]

When using DateMatchers.isDay(int, Month, int) with a date at start of day in GMT+1, the results are not as expected. Consider the following test :

  @Test
  public void isDay_WhenStartOfDayInGmtPlus1_ThenOffsetShouldBeIgnored() {
    LocalDate firstDayOf2018 = LocalDate.of(2018, Month.JANUARY, 1);
    ZonedDateTime startOfFirstDayOf2018InGmtPlus1 = ZonedDateTime.of(firstDayOf2018, LocalTime.MIDNIGHT, ZoneId.of("GMT+1"));

    Date dateToCompare = Date.from(startOfFirstDayOf2018InGmtPlus1.toInstant());
    assertThat(dateToCompare,
      isDay(firstDayOf2018.getYear(), firstDayOf2018.getMonth(), firstDayOf2018.getDayOfMonth()));
  }

It fails with the following error :

java.lang.AssertionError: 
Expected: the same day as lun., 01 janv. 2018
     but: the day is lun., 01 janv. 2018
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
        ...

Although understandable, there are a multiple issues with this result :

• The error message is not appropriate
• The JavaDoc is not clear about this
• There is no possibility to specify that the arguments are local to the date to be matched

Maybe a new isLocalDay(int, Month, int) method would be nice ?

[stewbis]

Date doesn't have a concept of timezone, it stores the milliseconds since the unix epoch based of UTC. The date you created is 23:00 31st Dec 2017 so when checking if it's on the 1st Jan 2018 it doesn't match. The error message is wrong because it's using the locale timezone but the result is correct.

To support cases where you want to check the isDay in a specific timezone using Java Date it would be clearer to add an overload to support passing ZoneId or TimeZone into the isDay call which then is used as the basis for the test. So in effect the test would be like:

assertThat(date, isDay(2018, JANUARY, 1, ZoneId.of("GMT+1"));

This makes the timezone in explicit and supports a wider range of use cases if you want to test if it's a specific date in timezones other that your Local one.

[tnaskali]

I've started to implement this feature and here's my first thoughts :

• in DateWrapper the call to wrapped.truncatedTo(accuracy) must be changed because this always truncates the instant in the UTC point of view. I'm thinking about using a ZonedDateTime instead of an Instant as the wrapper as this would truncate according to the desired Zone
• In DateWrapper(LocalDate) it seems wrong to set the time to NOON. MIDNIGHT is a better choice when time zones start to get involved.
• Overloading every method is problematic because : -- it doubles the size of the DateMatchers class which is already quite large -- The extra zone argument must be in first position everywhere because of the methods that take vararg parameters (isDayOfWeek(DayOfWeek...)) which make the API less readable I was thinking about a chained call like assertThat(date, isDay(2018, JANUARY, 1).atZone("GMT+1")); made possible by introducing a common superclass to all matchers and exposing the atZone(ZoneId) method in it

[stewbis]

This issue can now be close;d the atZone fluent method allows for replacement of the default timezone

[Alecsvan]

I beleive the following example is related to the same issue: final ZonedDateTime date = ZonedDateTime.of(2000,1,1,0,0,0,0,ZoneId.of("UTC")); assertThat(date, ZonedDateTimeMatchers.sameDay(date));

java.lang.AssertionError: Expected: the same day as Fri, 31 Dec 1999 but: the day is Sat, 01 Jan 2000

One of the days in this assertion somehow moved from UTC to my local timezone.

[stewbis]

Hi, the test would need to be changed to anchor it in UTC e.g.

final ZonedDateTime date = ZonedDateTime.of(2000,1,1,0,0,0,0,ZoneId.of("UTC")); assertThat(date, ZonedDateTimeMatchers.sameDay(date).atZone(ZoneIds.UTC);

[Alecsvan]

I should say that is quite an unexpected behavior to add zone to an already zoned date. It is even more painful if I try to use sameInstant method and getting the same result.

[stewbis]

Hi Alecsvan, that's a good point and I missed the fact that in your example test you used the same date. I agree the date should always match itself, the matchers make no sense otherwise. I'm raising a new issue for this because it should work

[stewbis]

New issue https://github.com/eXparity/hamcrest-date/issues/32 raises for sameDay not matching using zoned date time. @Alecsvan would you be OK to supply your timezone so that I can make it explicit in the issue. Feel free to update the issue 32 with the information. Thanks, @stewbis

[Alecsvan]

Sure, added the timezone. Thanks