eXparity / hamcrest-date

A Java library which provides a suite hamcrest matchers for matching dates, times, and moments in time
BSD 3-Clause "New" or "Revised" License
70 stars 11 forks source link

sameHourOfDay test broke after upgrade, semantics are unclear to me #35

Closed flyaruu closed 3 years ago

flyaruu commented 4 years ago

Hey all, I've upgraded from 2.0.5 to 2.0.7, the following test succeeds in <2.0.7, and fails in 2.0.7

(hope that Kotlin is not a problem)

    @Test
    fun `Test hour matcher`() {
        val zonedTime = ZonedDateTime.now()
        val utcZonedTime = ZonedDateTime.now(ZoneId.of("UTC"))
        assertThat(zonedTime, sameHourOfDay(utcZonedTime))
    }

So does sameHourOfDay mean same hour in the selected time zone, or the same hour after correcting for time zone? I can't make out exactly what the supposed semantics are. If 2.0.7 is correct, I'd suggest adding a line of documentation.

stewbis commented 3 years ago

Hi, thanks for getting in touch. There were changes in which fixed several latent timezone issues and defaulting of conversions. The code had a bug in it before, the semantics should not have been to adjust times to the default timezone when comparing. The expectation is now correct. If the default timezone in the JVM the code is running is not UTC then the hour can't the same e.g. "now" in Paris would be 8am, now in "UTC" is 6am.

I'd have to try it, but if you did want to use adjustment semantics then the code below would do that

assertThat(zonedTime, sameHourOfDay(utcZonedTime).atZone(ZoneId.systemDefault())