Three dates are created in succession: (1) `startDate` on MetaTag:103, (2) `startTime` on HtmlConfiguration:265, and `date` on MetaTag:95. If dates (1) and (3) are equal, we then conclude that (2) must be the same as (1) and (3). If I read the intent correctly, this implication warrants the conditional logic on MetaTag:96.
This looks reasonable, provided we are not concerned with other date sorcery. Maybe one of these days we could switch to the more modern java.time API. Looks good to me. -Pavel > On 15 Jan 2020, at 00:23, Jonathan Gibbons <jonathan.gibb...@oracle.com> > wrote: > > Please review a fix for a problem that occurs when a test is run across > midnight. > > Although it is difficult to confirm the root cause, and equally difficult to > test, the root cause is believed to be a static final instance of > java.util.Calendar that is used to obtain the date written into the generated > files, and which is subsequently verified by tests. When javadoc is run > multiple times in the same JVM, as will occur when running the MetaTag.java > test, the static final Calendar may be initialized to a time that is outside > the range checked by the test. > > The fix is to replace the static instance by a non-static instance created in > HtmlConfiguration. > > The fix is noreg-hard, because it can only be fully tested by running within > milliseconds of midnight. It's remarkable that this has actually occurred > multiple times in productio build/test runs. > > -- Jon > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223536 > Webrev: http://cr.openjdk.java.net/~jjg/8223536/webrev/ >
