[
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)