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

Timezone issues with historically varying DST and Offsets rules

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: 8.0.3
    • Fix Version/s: 8.5.1
    • Component/s: Components
    • Security Level: Jimmy
    • Labels:
      None

      Description

      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

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

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