RFR: JDK-8272984: javadoc support for reproducible builds [v2]

[Hannes Wallnöfer]

On Mon, 24 Jan 2022 19:04:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseOptions.java line 370:
>> 
>>> 368:                         try {
>>> 369:                             date = ZonedDateTime.parse(arg, DateTimeFormatter.ISO_ZONED_DATE_TIME)
>>> 370:                                     .withZoneSameInstant(ZoneOffset.UTC);
>> 
>> I notice that the new option takes a date-time with timezone, but the timezone is discarded here (and the date-time is later converted to a java.util.Date). Since the purpose of this change is to enable reproducible builds, I guess it should be possible to define the timezone used in the "Generated by" comment (which as far as I can tell is the timezone of the local host).
>
> I went out of my way to ensure that the _output_ form was not affected, in case there is anyone relying on the existing format ... and yes, we have tests for that as well.
> 
> I'd be open to formally changing the format of the output timestamp, but I think that should be a separate RFE.

What I meant was not to change the format used in javadoc output but rather to preserve the time zone of the timestamp passed as `--date` option argument. Since `java.util.Date.toString()` always uses the default time zone, to reproduce a documentation bundle generated in a different time zone one would have to set the default time zone in addition to using the `--date` option. This could be avoided by retaining the `ZonedDateTime` with the original time zone instead of converting it to a `java.util.Date`. The following `DateTimeFormatter` instance could then be used to generate a timestamp string identical to the one produced by `Date.toString()` but with the correct time zone:

     DateTimeFormatter.ofPattern("EEE MMM dd HH:mm:ss zzz yyyy").withLocale(Locale.US);

-------------

PR: https://git.openjdk.java.net/jdk/pull/7171