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