(Just in case a future Java version changes what Z...

# announcements

[mathew murphy]

(Just in case a future Java version changes what ZonedDateTime will parse, or we switch to a different calendar or something...)

[Dominaezzz]

I think Java is backward compatible. Not your job to test that.

[LeoColman]

I think it's valid if you don't know the string to be parsed

[LeoColman]

As it might be invalid, and parse might return null

[mathew murphy]

The point is to get a ZonedDateTime value I can use in tests, and which isn't nullable.

[Dominaezzz]

Oh I understand now.

[Dominaezzz]

It's a bit overkill but .... sure I guess.

[Dominaezzz]

@Ruckus Ha, same.

[mathew murphy]

!! works too, obviously, but IDEA suggested replacing it

[Dominaezzz]

Can ZonedDateTime be constructed without parsing? (I guess that doesn't quite solve the problem).

[Dominaezzz]

Rip, still platform type in that case.

[Dominaezzz]

It's an issue because it brings us back to square one.

[Dominaezzz]

The square of whether one should explicitly check the nullability of the returned value.

[mathew murphy]

val zdt = ZonedDateTime.of(2019,7,19,14,19,5,0, ZoneId.ofOffset("",ZoneOffset.ofHours(-5)))

[mathew murphy]

So much better 😛

[Dominaezzz]

I guess in conclusion, it's more on the unreasonable side of things.