[
https://jira.codehaus.org/browse/MPIR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated MPIR-278:
--------------------------------
Description:
There are some serious issues with the Actual Time (GMT) column on the
generated Project Team page. I describe both issues in detail below, and then
analyze and provide a possible solution. These issues all stem from how the
JavaScript init() and offsetDate() functions are written.
*Problem 1: Dates/Times are not correct*
See the attached screenshot for reference. This screenshot was taken on Monday,
May 13 at 12:10:32 Central Time. This is 13:10 Eastern Time, 10:10 Pacific
Time, and Tuesday 2:10 Tokyo Time.
However, the screenshot shows the Central Time row time as 11:10 (an hour
behind), the Eastern Time row as 12:10 (an hour behind), and the Pacific Time
rows as 9:10 (an hour behind). If this is near the midnight boundary, the dates
will be wrong, too. Only the Tokyo Time row is correct. This is a Daylight
Savings Time bug.
*Problem 2: Time zones are not correct, stretch the screen, and are unnecessary*
Even though (with the exception of two) all rows are in different time zones,
they all display "GMT-0500 (CDT)." This is the browser time. If you view this
page on a computer in a different time zone, it displays that time zone.
This is how it displays in Chrome and Safari. In Internet Explorer, the time
zone does not display at all (just date and time). In FireFox, it's worse:
"GMT-0500 (Central Daylight Time)." This last one stretches the screen
horizontally and causes other columns to scrunch up, which is not desirable.
Really, the time zone isn't even necessary here. There's already a Time Zone
column on the page, and it is always displayed when Actual Time (GMT) is
displayed. The fact that it's wrong and conflicts with the Time Zone column is
confusing. The fact that it stretches the page in FireFox is frustrating. The
fact that it doesn't display in all browsers is inconsistent.
*Analysis*
All of these problems boil down to the generated JavaScript used to display
this data:
{code:javascript}function offsetDate(id, offset) {
var now = new Date();
var nowTime = now.getTime();
var localOffset = now.getTimezoneOffset();
var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset *
60 * 1000 );
var developerDate = new Date(developerTime);
document.getElementById(id).innerHTML = developerDate;
}
function init(){
offsetDate('developer-0', '-8');
offsetDate('developer-1', '-5');
offsetDate('developer-2', '-8');
offsetDate('developer-3', '9');
offsetDate('developer-4', '-6');
}
window.onLoad = init();{code}
The time being wrong is caused by the {{init()}} method having a static offset
for all columns. The Java code that generates this JavaScript uses the offset
returned by {{TimeZone.getTimeZone(tz).getRawOffset()}} instead of the zone
name. This offset is the before-Daylight Savings Time offset. JavaScript does
not adjust this offset (because offsets do not contain DST rules, and because
JavaScript doesn't have a way to create dates in a different time zone anyway)
for Daylight Savings Time dates, and thus for 8 months out of the year the
offset is wrong for any developers in time zones that observe Daylight Savings
Time.
The time zone being wrong is caused by the fact that, in order to display the
date, the code simply converts the offset from hours to milliseconds and adds
it to a date in the browser's time zone to have a different time stamp. As a
result, the time zone doesn't change, but the time does. The correct may to
achieve this is to create a date with the some timestamp in a different time
zone, not to create a date with a different timestamp in the same time zone.
The fact that the date and time display differently in different browsers is
due to the fact that no date formatting is used, and thus the browser's Date
toString is relied upon, but this is implemented differently in nearly every
browser.
*Proposed Solution*
Instead of relying on the browser's Date object, which is unreliable and
contains no time zone-changing support, let's use a third-party date object
instead. Moment.js [1] and its new timezone [2] module should be sufficient.
Looks like the timezone module should be released any day now. Since Moment.js
is available on a CDN (hosted) like jQuery, we won't have to include that file
in the generated siteââ¬âit will just be linked to in a {{<script src>}}.
Once the time zone module is released, you could replace that JavaScript code
with something like this:
{code:javascript}function offsetDate(id, offset) {
var developerDate;
if (typeof offset === 'number') { // if <timezone> is offset number
var now = new Date();
developerDate = moment(
now.getTime() + (offset * 60 * 60 * 1000) +
(now.getTimezoneOffset() * 60 * 1000)
);
} else { // if <timezone> is time zone name
developerDate = moment().tz(offset);
}
document.getElementById(id).innerHTML = developerDate.format('ddd MMM D YYY
HH:mm:ss');
}
function init(){
offsetDate('developer-0', 'America/Los_Angeles');
offsetDate('developer-1', 'America/New_York');
offsetDate('developer-2', 'America/Los_Angeles');
offsetDate('developer-3', 'Asia/Tokyo');
offsetDate('developer-4', 'America/Chicago');
offsetDate('developer-5', -2); // if <timezone> is offset number instead of
TZ name, use number literal
}
window.onLoad = init();{code}
[1] http://momentjs.com/
[2] https://github.com/timrwood/moment/issues/482
was:
There are some serious issues with the Actual Time (GMT) column on the
generated Project Team page. I describe both issues in detail below, and then
analyze and provide a possible solution. These issues all stem from how the
JavaScript init() and offsetDate() functions are written.
*Problem 1: Dates/Times are not correct*
See the attached screenshot for reference. This screenshot was taken on Monday,
May 13 at 12:10:32 Central Time. This is 13:10 Eastern Time, 10:10 Pacific
Time, and Tuesday 2:10 Tokyo Time.
However, the screenshot shows the Central Time row time as 11:10 (an hour
behind), the Eastern Time row as 12:10 (an hour behind), and the Pacific Time
rows as 9:10 (an hour behind). If this is near the midnight boundary, the dates
will be wrong, too. Only the Tokyo Time row is correct. This is a Daylight
Savings Time bug.
*Problem 2: Time zones are not correct, stretch the screen, and are unnecessary*
Even though (with the exception of two) all rows are in different time zones,
they all display "GMT-0500 (CDT)." This is the browser time. If you view this
page on a computer in a different time zone, it displays that time zone.
This is how it displays in Chrome and Safari. In Internet Explorer, the time
zone does not display at all (just date and time). In FireFox, it's worse:
"GMT-0500 (Central Daylight Time)." This last one stretches the screen
horizontally and causes other columns to scrunch up, which is not desirable.
Really, the time zone isn't even necessary here. There's already a Time Zone
column on the page, and it is always displayed when Actual Time (GMT) is
displayed. The fact that it's wrong and conflicts with the Time Zone column is
confusing. The fact that it stretches the page in FireFox is frustrating. The
fact that it doesn't display in all browsers is inconsistent.
*Analysis*
All of these problems boil down to the generated JavaScript used to display
this data:
{code:javascript}function offsetDate(id, offset) {
var now = new Date();
var nowTime = now.getTime();
var localOffset = now.getTimezoneOffset();
var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset *
60 * 1000 );
var developerDate = new Date(developerTime);
document.getElementById(id).innerHTML = developerDate;
}
function init(){
offsetDate('developer-0', '-8');
offsetDate('developer-1', '-5');
offsetDate('developer-2', '-8');
offsetDate('developer-3', '9');
offsetDate('developer-4', '-6');
}
window.onLoad = init();{code}
The time being wrong is caused by the {{init()}} method having a static offset
for all columns. The Java code that generates this JavaScript uses the offset
returned by {{TimeZone.getTimeZone(tz).getRawOffset()}} instead of the zone
name. This offset is the before-Daylight Savings Time offset. JavaScript does
not adjust this offset (because offsets do not contain DST rules, and because
JavaScript doesn't have a way to create dates in a different time zone anyway)
for Daylight Savings Time dates, and thus for 8 months out of the year the
offset is wrong for any developers in time zones that observe Daylight Savings
Time.
The time zone being wrong is caused by the fact that, in order to display the
date, the code simply converts the offset from hours to milliseconds and adds
it to a date in the browser's time zone to have a different time stamp. As a
result, the time zone doesn't change, but the time does. The correct may to
achieve this is to create a date with the some timestamp in a different time
zone, not to create a date with a different timestamp in the same time zone.
The fact that the date and time display differently in different browsers is
due to the fact that no date formatting is used, and thus the browser's Date
toString is relied upon, but this is implemented differently in nearly every
browser.
*Proposed Solution*
Instead of relying on the browser's Date object, which is unreliable and
contains no time zone-changing support, let's use a third-party date object
instead. Moment.js [1] and its new timezone [2] module should be sufficient.
Looks like the timezone module should be released any day now. Since Moment.js
is available on a CDN (hosted) like jQuery, we won't have to include that file
in the generated siteâit will just be linked to in a {{<script src>}}. Once
the time zone module is released, you could replace that JavaScript code with
something like this:
{code:javascript}function offsetDate(id, offset) {
var developerDate;
if (typeof offset === 'number') { // if <timezone> is offset number
var now = new Date();
developerDate = moment(
now.getTime() + (offset * 60 * 60 * 1000) +
(now.getTimezoneOffset() * 60 * 1000)
);
} else { // if <timezone> is time zone name
developerDate = moment().tz(offset);
}
document.getElementById(id).innerHTML = developerDate.format('ddd MMM D YYY
HH:mm:ss');
}
function init(){
offsetDate('developer-0', 'America/Los_Angeles');
offsetDate('developer-1', 'America/New_York');
offsetDate('developer-2', 'America/Los_Angeles');
offsetDate('developer-3', 'Asia/Tokyo');
offsetDate('developer-4', 'America/Chicago');
offsetDate('developer-5', -2); // if <timezone> is offset number instead of
TZ name, use number literal
}
window.onLoad = init();{code}
[1] http://momentjs.com/
[2] https://github.com/timrwood/moment/issues/482
Summary: Actual Time (GMT) column is all kinds of broken: times wrong,
time zones wrong, time zone stretches screen in Firefox (was: Actual Time
(GMT) column is all kinds of broken: times wrong, time zones wrong, time zone
stretches screen in FireFox)
> Actual Time (GMT) column is all kinds of broken: times wrong, time zones
> wrong, time zone stretches screen in Firefox
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: MPIR-278
> URL: https://jira.codehaus.org/browse/MPIR-278
> Project: Maven Project Info Reports Plugin
> Issue Type: Bug
> Components: project-team
> Affects Versions: 2.6
> Environment: Chrome, Safari, FireFox, Internet Explorer
> Reporter: Nicholas Williams
> Attachments: screenshot.png
>
>
> There are some serious issues with the Actual Time (GMT) column on the
> generated Project Team page. I describe both issues in detail below, and then
> analyze and provide a possible solution. These issues all stem from how the
> JavaScript init() and offsetDate() functions are written.
> *Problem 1: Dates/Times are not correct*
> See the attached screenshot for reference. This screenshot was taken on
> Monday, May 13 at 12:10:32 Central Time. This is 13:10 Eastern Time, 10:10
> Pacific Time, and Tuesday 2:10 Tokyo Time.
> However, the screenshot shows the Central Time row time as 11:10 (an hour
> behind), the Eastern Time row as 12:10 (an hour behind), and the Pacific Time
> rows as 9:10 (an hour behind). If this is near the midnight boundary, the
> dates will be wrong, too. Only the Tokyo Time row is correct. This is a
> Daylight Savings Time bug.
> *Problem 2: Time zones are not correct, stretch the screen, and are
> unnecessary*
> Even though (with the exception of two) all rows are in different time zones,
> they all display "GMT-0500 (CDT)." This is the browser time. If you view this
> page on a computer in a different time zone, it displays that time zone.
> This is how it displays in Chrome and Safari. In Internet Explorer, the time
> zone does not display at all (just date and time). In FireFox, it's worse:
> "GMT-0500 (Central Daylight Time)." This last one stretches the screen
> horizontally and causes other columns to scrunch up, which is not desirable.
> Really, the time zone isn't even necessary here. There's already a Time Zone
> column on the page, and it is always displayed when Actual Time (GMT) is
> displayed. The fact that it's wrong and conflicts with the Time Zone column
> is confusing. The fact that it stretches the page in FireFox is frustrating.
> The fact that it doesn't display in all browsers is inconsistent.
> *Analysis*
> All of these problems boil down to the generated JavaScript used to display
> this data:
> {code:javascript}function offsetDate(id, offset) {
> var now = new Date();
> var nowTime = now.getTime();
> var localOffset = now.getTimezoneOffset();
> var developerTime = nowTime + ( offset * 60 * 60 * 1000 )+ ( localOffset
> * 60 * 1000 );
> var developerDate = new Date(developerTime);
> document.getElementById(id).innerHTML = developerDate;
> }
> function init(){
> offsetDate('developer-0', '-8');
> offsetDate('developer-1', '-5');
> offsetDate('developer-2', '-8');
> offsetDate('developer-3', '9');
> offsetDate('developer-4', '-6');
> }
> window.onLoad = init();{code}
> The time being wrong is caused by the {{init()}} method having a static
> offset for all columns. The Java code that generates this JavaScript uses the
> offset returned by {{TimeZone.getTimeZone(tz).getRawOffset()}} instead of the
> zone name. This offset is the before-Daylight Savings Time offset. JavaScript
> does not adjust this offset (because offsets do not contain DST rules, and
> because JavaScript doesn't have a way to create dates in a different time
> zone anyway) for Daylight Savings Time dates, and thus for 8 months out of
> the year the offset is wrong for any developers in time zones that observe
> Daylight Savings Time.
> The time zone being wrong is caused by the fact that, in order to display the
> date, the code simply converts the offset from hours to milliseconds and adds
> it to a date in the browser's time zone to have a different time stamp. As a
> result, the time zone doesn't change, but the time does. The correct may to
> achieve this is to create a date with the some timestamp in a different time
> zone, not to create a date with a different timestamp in the same time zone.
> The fact that the date and time display differently in different browsers is
> due to the fact that no date formatting is used, and thus the browser's Date
> toString is relied upon, but this is implemented differently in nearly every
> browser.
> *Proposed Solution*
> Instead of relying on the browser's Date object, which is unreliable and
> contains no time zone-changing support, let's use a third-party date object
> instead. Moment.js [1] and its new timezone [2] module should be sufficient.
> Looks like the timezone module should be released any day now. Since
> Moment.js is available on a CDN (hosted) like jQuery, we won't have to
> include that file in the generated siteââ¬âit will just be linked to in a
> {{<script src>}}. Once the time zone module is released, you could replace
> that JavaScript code with something like this:
> {code:javascript}function offsetDate(id, offset) {
> var developerDate;
> if (typeof offset === 'number') { // if <timezone> is offset number
> var now = new Date();
> developerDate = moment(
> now.getTime() + (offset * 60 * 60 * 1000) +
> (now.getTimezoneOffset() * 60 * 1000)
> );
> } else { // if <timezone> is time zone name
> developerDate = moment().tz(offset);
> }
> document.getElementById(id).innerHTML = developerDate.format('ddd MMM D
> YYY HH:mm:ss');
> }
> function init(){
> offsetDate('developer-0', 'America/Los_Angeles');
> offsetDate('developer-1', 'America/New_York');
> offsetDate('developer-2', 'America/Los_Angeles');
> offsetDate('developer-3', 'Asia/Tokyo');
> offsetDate('developer-4', 'America/Chicago');
> offsetDate('developer-5', -2); // if <timezone> is offset number instead
> of TZ name, use number literal
> }
> window.onLoad = init();{code}
> [1] http://momentjs.com/
> [2] https://github.com/timrwood/moment/issues/482
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
