Steps to Reproduce

run current 9.6.0 FL with a datebox:

<zk><datebox/></zk>

Current Result

Datebox receives an unusable format: "Apr 2, 1"

Received from server-side (with a browser request for "Accept-Language: en-US,en;q=0.9,fr;q=0.8"

receieved: ['zul.db.Datebox','mCCU0*',{format:'MMM d, y'* ...

Since default format uses a 1 digit year, selecting a date in 2021 in the datebox popup will actually set a date of 2001

no value, open current day:

Selecting a value in current month, parsed value in 2001:

Expected Result

Default return a usable format

Debug Information

behavior introduced in https://tracker.zkoss.org/browse/ZK-4745

Before this feature implementation, the client widget would still receive the format string with a single y digit, but would ignore it and treat "y" as "yy" for the purpose of displaying the date.

Not sure if that was a bug or an existing workaround.

JVM 11+ uses the unicode standard for date / time formats.

See here:

https://www.unicode.org/cldr/cldr-aux/charts/33/by_type/date_&_time.gregorian.html#14164b88b71705de

(warning big page, open in FF if fails in chrome) 

DateFormat.DEFAULT is used in datebox:

https://github.com/zkoss/zk/blob/master/zul/src/org/zkoss/zul/Datebox.java#L239

It resolves to DateFormat.MEDIUM

https://docs.oracle.com/javase/7/docs/api/java/text/DateFormat.html#DEFAULT

Workaround

according to java9 release note: https://www.oracle.com/java/technologies/javase/9-relnotes.html#JDK-8008577

setting java.locale.providers to a value with COMPAT ahead of CLDR.

-Djava.locale.providers=COMPAT,CLDR,SPI

The property "java.locale.providers" is only read at the Java runtime startup, so the later call to System.setProperty() won't have effect. (See LocaleServiceProvider API ).

or just specify format: 

<datebox format="yyyy/MM/dd"/>