java.time formatting troubles with time zones

[Daniel Dekany <da...@gmail.com>]

I was trying to progress with FREEMARKER-35. So we have settings akin to
the good old data_format/datatime_format/time_format, but they are named
after the java.time temporal classes, like zoned_date_time_format,
local_date_time_format, etc. The setting value is a pattern as defined by
java.time.format.DateTimeFormatter, like "uuuu-MM-dd HH:mm". (Actually it
can also have other kind of values, like "medium", "iso", etc. but for now
it doesn't matter.)

Problem 1: When the zone is not shown

If a DateTimeFormatter doesn't show the time zone (or the offset), it of
course still will not convert it to the current time zone (dictated by the
FreeMarker time_zone setting). So if I have ZonedDateTime 2000-01-01
15:00+05, and the current time_zone is +02, and the format doesn't contain
a time zone part, you just see "2000-01-01 15:00", and not "2000-01-01
12:00". That's unlike with java.util.Date, where no such accident can
happen; if you see no time zone, then you see the local date-time in the
current time zone. But unlike java.util.Date, ZonedDateTime doesn't store
an instant of time, instead it stores a local date-time and a zone. So I'm
not supposed to mess with that zone, just show it as is. But on the same
time, I can't tell if the DateTimeFormatter will actually show the zone (I
don't see an API to query that). Worse, typical local default formats like
"MEDIUM" and "SHORT", do not contain time zone (checked on Java 8 and 13,
with a dozen of locales). So users will burn themselves with this, showing
misleading information.

Proposed solution:
When a new format is provided to FreeMarker, it will detect if the output
of that format is affected by the zone (or offset) of the input temporal,
by providing two dummy inputs that only differ in time zone, and see if the
outputs differ. That's admittedly a dirty hack (and bit of runtime
overhead), but I see no API to query such information about a
DateTimeFormatter. If I have found that the zone (or offset) is not shown,
they I will convert the input temporals to the current time zone  as part
of the formatting. Otherwise, don't do time zone conversion, and so the
zone will be shown as is. So we deviate from what java.time does, but
hopefully do what's safest, and practical.


Problem 2: Default formats are failing for some input types

It's about DateTimeFormatter.ofLocalizedXxx(FormatStyle), where
FormatStyle can be FULL, LONG, MEDIUM, and SHORT. The goal of this API is
give the default formatter for given locale, each my uses a different
pattern internally.

The problem is that the provided formatters only works reliably for
ZonedDateTime and LocalDate, but not for LocalDateTime, OffsetDateTime, or
OffsetTime, because the localized pattern my displays the time zone, even
if your input type has no such field! So if you try to format a
LocalDateTime with LONG, you get an exception with an otherwise quite
unhelpful error message. So how to shield the users from this?

Based on a dozen of locales and Java 8 and 13, it seems that MEDIUM and
SHORT never contains zone, so they are safe, while FULL and LONG always do.
Although, it's just an observation, I see no such promise in the API.
Luckily, our default format will be MEDIUM, as that's the default for
java.util.Date too. (That's also why Problem 1 has a big impact.) So we are
kind of fine there... hoping that they won't add time zone to the MEDIUM
format of some locale in the future.

Other than that, I don't know what to do if someone uses LONG format for
example. I think adding and displaying zones to temporals that are not
zoned by their very nature (LocalDateTime, etc.), is not acceptable. We had
one job after all: showing data, without distortion. We don't know if that
LocalDateTime or LocalTime is the instant in a given time zone, that we
would show, if we add the current time zone to it. There's also the wild
possibility of somehow editing the zone out of the format given, but I
don't see how, as I can't even get hold of the pattern of the
DateTimeFormatter returned by DateTimeFormatter.ofLocalizedXxx. So, for
now, I plan to let it fail, except I will try if it still fails if I have
zone, and if it doesn't, then tell the user in the error message that this
format only works for inputs that contains a time zone. We will have to add
some built-in to explicitly add a time zone to local stuff.

Anybody has some other ideas, or wants me to not do some of these, please
tell it!

-- 
Best regards,
Daniel Dekany