On Thu, 12 Mar 2026 13:44:37 GMT, Mikhail Yankelevich
<[email protected]> wrote:
>> test/jdk/java/security/cert/X509Certificate/VerifyDefault.java line 179:
>>
>>> 177: () -> cert.checkValidity(
>>> 178: Instant.parse("2012-05-26T16:47:26Z")));
>>> 179:
>>
>> Maybe you can check both `Instant` and `Date`. After all, we still need to
>> support the old methods.
>>
>> You can also add new test to check the consistency.
>
> Ok, will add the test in the next commit.
>
> Just to clarify, what do you mean by the consistency check, isn't it covered
> by
>
> Asserts.assertEquals(notBeforeDate.getTime(),
> notBeforeInstant.toEpochMilli());
> Asserts.assertEquals(notAfterDate.getTime(),
> notAfterInstant.toEpochMilli());
>
>
> I think I might be misunderstanding you
Yes, this is about consistency. If it's already covered, then good.
>> test/jdk/sun/security/util/DerInputBuffer/TimeParsing.java line 133:
>>
>>> 131: Instant d1Instant = decodeUTCInstant(b);
>>> 132: if (!d0.equals(d1)
>>> 133: && d0.toInstant().toEpochMilli() !=
>>> d1Instant.toEpochMilli()) {
>>
>> Why `&&`? You always call this with a fixed milliseconds value, instead of
>> random `now()`.
>
> This way it tests that `decodeUTCInstant` and `decodeUTC` are returning
> equivalent results. Just in case that there is a difference in nanos in the
> future in `byte[] b` as `Date` supports up to millis
Not worth anticipating that. If it really happens, maybe we have a bug
somewhere.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30047#discussion_r2927468380
PR Review Comment: https://git.openjdk.org/jdk/pull/30047#discussion_r2927472344
