run the attached example dateboxes.zul
while all the dates have been initialized with 0:00 in their respective timezone the client side displays a different date/time
extreme cases are shown in the datebox d3 and d4 where timezones have irregular historical offsets, and DST rules
Portugal/Lisbon had a 36minute offset before 1912
Germany had 2 different DST offsets between 1945/1947 (winter +1, spring/autumn +2, summer +3)
datebox should display the times as initialized at server side
Since there is no regular pattern I attached a JUnit test to loop through multiple days in a sequence and log all irregularities
the methods Datebox.marshall / unmarshall, perform a conversion from foreign timezone to the current system/preferred timezone, using a util function org.zkoss.util.Dates.getTimezoneOffset() which doesn't take historical timezone changes into account.
Even when applying historical offsets using this prototypic implementation problem remain in certain periods.
The attached JUnit test (ForeignTimeZoneTest.java) can be run using different system and foreign timezones to identify the problematic days between timezones easily.
There may be a large number of yet undiscovered combinations causing trouble