Documenting here two reports that I have found about this case.
First is this thread:
In that thread I did some tests and showed some cases failing.
Some of my comment there:
From my debug session going very very deep in the problem I noticed when I fill the datebox with 07201810 - the value passed through zk is something like "1810.7.20.4.56.16.0" - so until some point the string is still july-20.
Then it arrives to org.zkoss.zk.au.AuRequest->parseType - line 108 (breakpoint here)
This calls org.zkoss.json.JSONs->j2d
and there the string is converted to a date with july-19
A bit more of research on this, found:
This commit made a change on the timezone on JSONs (changed from zk
version 8.0 to 8.5)
Probably we need to adapt our code to that change.
Yesterday I received the second report about this - easily reproducible.
If the server is on timezone America/Sao_Paulo the same issue happens with dates >= Oct-21/2019
Environment can be simulated adding this parameter in eclipse or to the IDEMPIERE_JAVA_OPTIONS in server:
In mattermost chat
pointed to the solution of this issue. Changing the timezone to GMT-3 works, that is probably caused because Brazil changed the daylight and timezone in 2019.
Setting the breakpoint in the same line org.zkoss.zk.au.AuRequest->parseType:108 leads to the same conclusion.
Researching more about this issue found this answer here:
And as a "workaround" if we can call it that way, I tested setting the -Duser.timezone=UTC and everything works fine in UTC, I suppose because there are no conversions between timezones.
Added some notes on to think further about this possibility.
java time library use database from https://www.iana.org/time-zones
i saw that data on this file https://github.com/zkoss/zk/blob/master/zk/src/archive/web/js/zk/ext/moment-timezone-with-data.js
it said "version": "2019a". it's same my jdk-13 but i still get error (as i know you use update jdk-11 and version = "2019c")
> I tested setting the -Duser.timezone=UTC and everything works fine in UTC, I suppose because there are no conversions between timezones.
i test this way on fist place, but it seem not safe
old value on database maybe not sync, because getTime of UTC (new data) is difference by getTime of default timezone (old data)
at moment idempiere don't support multi timezone at webui but it can improve to support, this workaround void this improve
i will study moment-timezone-with-data.js to see why offset on date 03/28/2500 is difference
root course by Moment library https://github.com/moment/moment-timezone/issues/891
from year 2500 will get that error, because we know point of time get error can adjust (when read from database) as workaround
but it's not sure for other timezone
Thanks , I merged the pull request as it solves half of the problem.
About my two ideas above:
I tried this approach too, setting the timezone in UTC for the Datebox on WDateEditor and WDatetimeEditor.
The problem is that the zk class for Datebox uses an object of type Date to save the value - Date object in java doesn't have timezone information, it uses the default timezone.
A possible solution would be to implement a Datebox zk version that uses ZonedDateTime class instead of Date, but that's something must be solved in zk side I guess.
Having a ZonedDateTime would make possible to have a Datebox in UTC and that would avoid the timezone mismatch, and the conversion would be done just in java in WDateEditor side.
I think we can keep this on hold as a valid workaround was found, although is not the most useful for everybody.