Uploaded image for project: 'ZK'
  1. ZK
  2. ZK-3527

Timezone issues with historically varying DST and Offsets rules

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Normal Normal
    • 8.5.1
    • 8.0.3
    • Components
    • Security Level: Jimmy
    • None

      Steps to Reproduce

      run the attached example dateboxes.zul

      Actual Result

      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)

      Expected Result

      datebox should display the times as initialized at server side

      Debug Info

      Since there is no regular pattern I attached a JUnit test to loop through multiple days in a sequence and log all irregularities

      Root Cause

      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.

      	public static final long getTimezoneOffset(TimeZone timezone, Date date) {
      		return timezone.getOffset(date.getTime());
      	}
      

      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

      Workaround

            bobpeng bobpeng
            cor3000 cor3000
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - 0 minutes
                0m
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 week, 3 days, 4 hours
                1w 3d 4h