(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.

[Ruckus]

If that's the case, you have much bigger problems you need to worry about. You should be testing your code. If you can't trust the underlying standard library of your language, you either shouldn't be using that language, or you have some serious trust issues you need to work out.

[Ruckus]

(That may have been overly facetious. @Dominaezzz's answer is exactly right. It's not your job)

[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

[Ruckus]

There are 2 problems with that.
1. If you don't know the string to be parsed, that's already not a good test
2. This question was worded to suggest @mathew murphy is testing for breaking changes in java.time APIs, and not if they are being used correctly.

[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.

[Ruckus]

Ah, sorry, I misunderstood and assumed that was your entire test 🙂

[Dominaezzz]

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

[Dominaezzz]

@Ruckus Ha, same.

[mathew murphy]

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

[Ruckus]

In that case, you shouldn't need the the fail clause. It should return a platform type, which is safe to treat as not nullable.

[Ruckus]

If you don't like the platform type, just specify the type:

val zdt: ZonedDateTime = ZonedDateTime.parse("2019-07-19T14:19:05-05:00")

[Dominaezzz]

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

[Ruckus]

Yes, use ZonedDateTime.of(...)

[Dominaezzz]

Rip, still platform type in that case.

[Ruckus]

Why is that an issue?

[Ruckus]

The whole point of platform types is that Kotlin can't guarantee nullability one way or the other, so it leaves it up to you. In this case, it's perfectly reasonable for you to assume it's not.

[Dominaezzz]

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

[Ruckus]

What square is that? As far as I understand, square 1 was whether or not human reckoning of time is going to drastically change any time soon (no pun intended), which is in no way related to platform types...

[Dominaezzz]

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

[Ruckus]

I think platform types are a red herring in that question.

[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.