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.


> On 15 Jan 2020, at 00:23, Jonathan Gibbons <> 
> 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 
> 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:
> Webrev:

Reply via email to