Hi Daniel,
> Le 17 févr. 2022 à 08:40, Daniel Dekany 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
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.
On Mon, Dec 27, 2021 at 10:47 PM Daniel Dekany
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),
w
What's in FREEMARKER-35, for a few days now, already uses date_format,
time_format and datetime_format for the java.time values as well, and the
related new settings were removed. But translating the SimpleDateFormat
pattern syntax to DateTimeFormatter pattern syntax is not done yet, so for
now the
In many (certainly in most) projects it's not a realistic expectation that
they completely replace java.util.Date-s with Temporal-s at once. Even if
you think you have done it, it would be difficult to guarantee that no
java.util.Date will find its way into the data-model sometimes later, maybe
co
There was progress made in that branch like one month ago. More is needed,
and hopefully will be done this month.
Now, there are a few dilemmas with this feature branch (FREEMARKER-35).
Here's one of them.
For a long time we have the datetime_format, date_format, and time_format
settings for java
Hi,
This feature would really modernize Freemarker for us.
Is there any news on LocalDate support for Freemarker?
Anything we can do to speed things along?
With kind regards,
Geoffrey De Smet
On 02/10/2021 20:24, Daniel Dekany wrote:
Hi,
Not yet, but there's a FREEMARKER-35 branch that deals
Sounds like a plan ...
> On 07.10.2021, at 20:17, Daniel Dekany wrote:
>
> Thanks, for now I don't think you can help. But when it will be mostly
> done, looking for problems will be welcome.
>
> On Thu, Oct 7, 2021 at 7:53 PM Siegfried Goeschl
> wrote:
>>
>> Hi Daniel,
>>
>> Is there anythi
Thanks, for now I don't think you can help. But when it will be mostly
done, looking for problems will be welcome.
On Thu, Oct 7, 2021 at 7:53 PM Siegfried Goeschl
wrote:
>
> Hi Daniel,
>
> Is there anything I can help with, e.g. reviewing code, writing tests,
> checking documentation?
>
> I sho
Hi Daniel,
Is there anything I can help with, e.g. reviewing code, writing tests, checking
documentation?
I should be able to find some time and I already missed LocalData support
during my last project.
Thanks in advance,
Siegfried Goeschl
> On 02.10.2021, at 20:24, Daniel Dekany wrote:
Daniel,
That would be great.
Even without the built-ins, just avoiding all the java.util.Date bugs
will be worth it.
Context:
For the OptaPlanner project (also Apache License), we're using
Freemarker for:
- rendering the website optaplanner.org using JBake + Freemarker
- the optaplanner-ben
Hi,
Not yet, but there's a FREEMARKER-35 branch that deals with all the
java.time types. It works at the first sight, but actually will need a
significant amount of work before it can be released. I plan to put
aside time for a "sprint" on it near the end of October. We will see.
And yes, I also w
Hi all,
Does Freemarker have plans to support using java.time.LocalDate instead
of java.util.Date?
The latter is causing off-by-one errors for in our Freemarker templates
if executed in certain timezones (and adjusting the timezone opens
another can of worms).
See https://github.com/jbake-or
13 matches
Mail list logo
