I think the new text needs should be more specific:
The {@code FULL} and {@code LONG} styles typically require a time-zone.
When formatting using these styles, a {@code ZoneId} must be available,
either by using {@code ZonedDateTime} or {@link DateTimeFormatter#withZone}.
(testing shows that the other two styles appear to not use the time-zone.)
While it would be nice to support these styles when no time-zone is
available, that seems like an unrealistic goal.
Beyond this, the error message is terrible, eg:
Unable to extract value: class java.time.format.DateTimePrintContext$1
Unable to extract value: class java.time.LocalDateTime
Unable to extract value: class java.time.OffsetDateTime
This requires two separate changes.
1) Add toString() to the inner class at line 185 in DateTimePrintContext
2) At line 282 in DateTimePrintContext, the exception message needs to
record what is being queried - ZoneId, ZoneOffset, Chronology etc.
Something like:
if (query == TemporalQueries.zoneId() {
throw new DateTimeException("Unable to extract ZoneId from temporal:
" + temporal.getClass());
} else if (query == TemporalQueries.zoneOffset() {
throw new DateTimeException("Unable to extract ZoneOffset from
temporal: " + temporal.getClass());
} else ...
I'm happy for the error message problem to be fixed in a different
issue if desired.
Stephen
On 11 March 2016 at 20:19, Roger Riggs <roger.ri...@oracle.com> wrote:
> Please review java.time javadoc improvements to highlight a common
> misunderstanding
> about formatting elements that require a timezone in addition to the time.
> When using locale specific formatting, it may work if the locale formatting
> does not
> require a timezone or fail if the locale formatting requires a timezone and
> a timezone is not provided.
>
> ZoneDateTime or OffsetDateTime types should be used when formatting with
> locale
> dependent formatters.
>
> 8085887 : java.time.format.FormatStyle.LONG or FULL causes unchecked
> exception
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-format-8085887/
>
> Thanks, Roger
>
