You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Michael Osipov (JIRA)" <ji...@apache.org> on 2015/08/21 21:27:45 UTC

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

     [ https://issues.apache.org/jira/browse/MPIR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Osipov resolved MPIR-278.
---------------------------------
    Resolution: Later

Nick, I am closing this because no one took a stab to provide a good solution. As you can see I ahve disabled the column for now since the last release.

> 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://issues.apache.org/jira/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: Nick 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 was sent by Atlassian JIRA
(v6.3.4#6332)