I cannot reproduce this issue with current master (release-12), it was probably solved in zk.

Thanks @Hiep Lq, I merged the pull request as it solves half of the problem.

I see the other half is a bug in a javascript library, so, let's keep this open.

About my two ideas above:

is there a way to know which timezone/offset is javascript using and adjust the java code to use the same offset when converting back?

If I understood this right - java and javascript are using the same timezone, but as the libraries are different a mismatch on one side creates bad date on the other side, and you found and reported a bug in the javascript library moment-timezone.

is there a way to set Datebox or to indicate javascript to not use timezone at all, so we do the calculations (if required) just in java.

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.

Regards,

Carlos Ruiz

for refer: how to read IANA data
https://raw.githubusercontent.com/eggert/tz/master/tz-how-to.html

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

> is there a way to know which timezone/offset is javascript using and adjust the java code to use the same offset when converting back?

java time library use database from https://www.iana.org/time-zones
i guess zk javascript also same, because other case get correct and same offset for both side

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

1. old value on database maybe not sync, because getTime of UTC (new data) is difference by getTime of default timezone (old data)

2. 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