Just in case a future Java version changes what ZonedDateTim

Question

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

Dominaezzz · Answer

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

Ruckus · Answer

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 · Answer

That may have been overly facetious < Dominaezzz> s answer is exactly right It s not your job

LeoColman · Answer

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

LeoColman · Answer

As it might be invalid and `parse` might return null

Ruckus · Answer

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 · Answer

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

Dominaezzz · Answer

Oh I understand now

Ruckus · Answer

Ah sorry I misunderstood and assumed that was your entire test slightly smiling face

Dominaezzz · Answer

It s a bit overkill but sure I guess

Dominaezzz · Answer

< Ruckus> Ha same

mathew murphy · Answer

` ` works too obviously but IDEA suggested replacing it

Ruckus · Answer

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 · Answer

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 · Answer

Can `ZonedDateTime` be constructed without parsing I guess that doesn t quite solve the problem

Ruckus · Answer

Yes use `ZonedDateTime of `

Dominaezzz · Answer

Rip still platform type in that case

Ruckus · Answer

Why is that an issue

Ruckus · Answer

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 · Answer

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

Ruckus · Answer

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 · Answer

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

Ruckus · Answer

I think platform types are a red herring in that question

mathew murphy · Answer

`val zdt = ZonedDateTime of 2019 7 19 14 19 5 0 ZoneId ofOffset ZoneOffset ofHours 5 `

mathew murphy · Answer

So much better stuck out tongue

Dominaezzz · Answer

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