Dates from data/*.yml file all have off-by-one errors on machines with american timezones

[ge0ffrey]

The automatic publisher of the optaplanner.org website has off-by-one-errors for dates. Locally I cannot reproduce this bug.

For example, all the event dates published on optaplanner.org live are wrong:

But in the events.yml file, they are correct:

- eventId: 20211012-icodejavaafrica
  eventOrganization: "I code Java Africa"
...
  date: 2021-10-12


- eventId: 20211025-joker
  eventOrganization: "Joker"
...
  date: 2021-10-25


- eventId: 20211119-devoxxua
  eventOrganization: "Devoxx Ukraine"
...
  date: 2021-11-19

I suspect this because of the timezone setting of the virtual machine and/or OS. I managed to reproduce locally by doing this:

git clone https://github.com/kiegroup/optaplanner-website.git
cd optaplanner-website

 mvn clean generate-resources
 // Notice how the dates are correct: Africa Tue, Joker Mon, ... 
 export TZ="America/Sao_Paulo"
 mvn clean generate-resources
 // Notice how the dates are incorrect: Africa Mon (wrong), Joker Sun (wrong), ... 

[ge0ffrey]

Interestingly, post.date dates are fine on that machine (no one-off-error).

[ge0ffrey]

I bet java.util.Date is responsible for this. It's a shame that Freemarker is not using java.time.LocalDate (Java 8+) yet.

May java.util.Date burn in hell, where it was forged.

[jonbullock]

Based on the Yaml spec it appears those date values will have a time of 00:00:00 (start of the day) and UTC timezone so when the local timezone of the machine is applied (i.e. -05:00) you get a date of the previous day.

If you add <#setting time_zone="GMT"> this appears to fix the date display issue by ignoring the local timezone, however I'm unsure if this causes any other issues.

[ge0ffrey]

@jonbullock Any chance JBake can just fix this for us out the box?
A) Either by defaulting the YAML parser to use the same timezone as the rest of JBake
B) or by getting YAML/Freemarker etc to use java.time.LocalDate, the modern, reliable time library (*), instead of The Thing That Was Created In Hell (java.util.Date)?
(I do suspect B) is more work)

(*) Requires at least Java 8, but I suspect all these techs now require at least Java 8 (if not 11).

[jonbullock]

Yeah still working towards that goal, last comment was a dump of my progress so far.

[jonbullock]

OK so after more investigation, Snakeyaml is using the same timezone as the rest of JBake. I was curious as to why this issue didn't seem to affect other dates (i.e. dates for content files) but after further research it does affect them in the same way. However it's probably not been noticed due to the content having a time component that meant the timezone offset didn't affect the day component.

I looked into option B and it's quite straight forward to use LocalDate in Snakeyaml, however this type is not yet supported in Freemarker so changes would be required to templates.

There is the option for JBake to explicitly override the local TimeZone (maybe via jbake.properties) in similar fashion to what it does with locale?

[ge0ffrey]

Thank you for the investigation, Jon. Much appreciated. I've opened a discussion the Freemarker mailing list about LocalDate support.

I looked into option B and it's quite straight forward to use LocalDate in Snakeyaml, however this type is not yet supported in Freemarker so changes would be required to templates.

I am happy to make such changes. It would be great to have a jbake.properties option to turn this behavior on (preferJavaTime=true ?) even if it's just for yaml. Anything to ban the use of java.util.Date.

There is the option for JBake to explicitly override the local TimeZone (maybe via jbake.properties) in similar fashion to what it does with locale?

Not sure what you mean here. I think that if jbake.properties fixes a timezone, then all techs (snakeyaml, freemarker, etc) should be explicitly set to use that. If it doesn't fix a timezone, they should all be using the default timezone of the process (= of the OS). In both cases, java.util.Date's won't suddenly change timezone, because there will only be one timezone.

[ge0ffrey]

@jonbullock is the fix from your fork coming to blessed?