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)