[MPIR-278] Actual Time (GMT) column is all kinds of broken: times wrong, time zones wrong, time zone stretches screen in Firefox

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Later
• Affects Version/s: 2.6
• Component/s: team
• Environment: Chrome, Safari, FireFox, Internet Explorer
• Assignee: Unassigned
• Reporter: Nick Williams
• Created: 13/May/13 15:44
• Updated: 29/Dec/15 00:27
• Resolved: 21/Aug/15 19:27

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:

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();

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:

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();

[1] http://momentjs.com/
[2] https://github.com/timrwood/moment/issues/482

Sub-Tasks

• Disable/remove dev/contrib current time generation because it is broken: Closed