You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Mansour Rahimi (JIRA)" <ji...@apache.org> on 2019/07/17 23:54:00 UTC

[jira] [Created] (WICKET-6689) ClientProperties.getTimeZone() has some issue when DST and UTC offsets are different

Mansour Rahimi created WICKET-6689:
--------------------------------------

             Summary: ClientProperties.getTimeZone() has some issue when DST and UTC offsets are different
                 Key: WICKET-6689
                 URL: https://issues.apache.org/jira/browse/WICKET-6689
             Project: Wicket
          Issue Type: Bug
          Components: wicket
    Affects Versions: 9.0.0-M2
            Reporter: Mansour Rahimi


So ClientProperties.getTimeZone() got UTC offset 11 and DST offset 10 (Australia Sydney), and it picked the wrong one (UTC +11). The issue is the way it's calculating the UTC-DST difference and looking up in the available time zone IDs.
{code:java}
					if (dstTimeZone != null &&
						dstTimeZone.getRawOffset() != timeZone.getRawOffset())
					{
						int dstSaving = dstTimeZone.getRawOffset() - timeZone.getRawOffset();
						String[] availableIDs = TimeZone.getAvailableIDs(timeZone.getRawOffset());
						for (String availableID : availableIDs)
						{
							TimeZone zone = TimeZone.getTimeZone(availableID);
							if (zone.getDSTSavings() == dstSaving)
							{
								// this is a best guess... still the start and end of the DST should
								// be needed to know to be completely correct, or better yet
								// not just the GMT offset but the TimeZone ID should be transfered
								// from the browser.
								timeZone = zone;
								break;
							}
						}
					}
{code}
If _dstTimeZone.getRawOffset() < timeZone.getRawOffset()_ then _dstSaving_ is negative and it would never find any zone in the _availableIDs_.


 I'm sending a PR for this.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)