Nicholas Williams created MPIR-278:
--------------------------------------
Summary: 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 2.x 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
