On Mon, 24 Jan 2022 19:04:18 GMT, Jonathan Gibbons <j...@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
