Hi Daniel,
> Le 17 févr. 2022 à 08:40, Daniel Dekany <daniel.dek...@gmail.com> a écrit :
>
> Just to keep us updated... This wasn't abandoned, but dragging. Part of the
> reason is that I keep discovering complications that need to be addressed.
> But it will be done, and when it's done, that will be released as soon as
> possible of course.
That sounds great!
More comments below.
> On Mon, Dec 27, 2021 at 10:47 PM Daniel Dekany <daniel.dek...@gmail.com>
> wrote:
>
>> Now the "translating SimpleDateFormat pattern syntax to DateTimeFormatter
>> pattern syntax" part is done. Actually it parses the pattern, and builds a
>> DateTimeFormatter from it directly (so there's no translated pattern). It
>> seems to work well enough (after quite a few corner cases were addressed),
>> which is a relieft, as this was crucial for using common format settings
>> among Date-s and java.time Temporal-s.
>>
>> Will continue with the fancier extended aka. "version 2" format. See
>> question about its syntax in previous mail, if you want to influence how
>> it will be.
>>> … ...
>>> - version:
>>> - "1": SimpleDateFormat syntax, which is also the default
>>> - "2": for DateTimeFormatter syntax + FreeMarker
>>> extensions (which makes semicolon reserved). Example:
>>> 'HH:mm[X];version=2'
>>> - for${Type}, like forLocalTime: Specify a different pattern if the
>>> value class is this
>>>
>>> Good news is, these can be added without breaking backward compatibility,
>>> and without extra setting to enable the extended syntax, because the letter
>>> "v" in "version", and "f" in "for${Type}" (and some more letters) are
>>> invalid pattern characters for SimpleDateFormat.
>>>
>>> I wonder if ";version=2" is good. While something like
>>> ";javaDotTimePatternSyntax=true" is more self explanatory, it's also
>>> comically verbose. So, I'm afraid people will have to search for the
>>> meaning with any sane syntax we can come up with. But if they have to
>>> anway, what if we go wilder, and say that the new syntax is indicated with
>>> an initial "v2:", as in "v2:HH:mm[X]". It's less verbose. Also, it avoids
>>> the somewhat confusing behavior that wherever you put ";version=2", it
>>> applies to the whole pattern. WDYT? Any other ideas?
I am OK with that idea.
>>> Different... FREEMARKER-35 now also handles adjusting the Java format
>>> time styles (short, medium, long, full) for LocalDateTime, LocalTime, and
>>> OffsetTime. Before that, you often ended up with runtime error, either
>>> because the style wanted to show the zone that's not available in local
>>> temporal, or because the style did not show the offset that is often to
>>> display an OffsetTime if DST is a possibility. Earlier I said that I add
>>> settings to set the upper and lower bounds of the time style for these
>>> types. Instead, I made this adjustment entirely dynamic and automatic, and
>>> there are no settings to worry about. I realized it has to be like that,
>>> because what the proper closest usable time style depends on the locale, or
>>> even Java version and local Java customizations.
>>>
>>>
>>> On Mon, Dec 13, 2021 at 1:01 PM Geoffrey De Smet <ge0ffrey.s...@gmail.com>
>>> wrote:
>>>
>>>> Good point, Daniel
>>>>
>>>> I agree on the need for the mixed situation support.
>>>>
>>>> About the same pattern, I also agree losing simplicity is not worth it
>>>> and BC is needed for datetime_format, date_format, and time_format.
>>>> Having access to LocalDate etc will be well worth that wrinkle.
Yes
>>>> With kind regards,
>>>> Geoffrey De Smet
>>>> On 13/12/2021 12:27, Daniel Dekany wrote:
>>>> … ...
>>>>> So you don’t want to
>>>>> consider if it's a java.util.Date, or a LocalDateTime, or an
>>>>> OffsetDateTime, or a ZonedDateTime, or an Instant. Most of the time at
>>>>> least, you don't want to present them differently. There I intend to
>>>>> remove
>>>>> all these new settings, except year_format, and year_month_format.
>>>>> Everything else will be governed by just datetime_format, date_format, and
>>>>> time_format.
>>>>>
>>>>> What do you guys think?
>>>>>
>>>>> +1 (non-contributor)
Yes
— Denis.
