[
https://jira.codehaus.org/browse/MPIR-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=331862#comment-331862
]
Michael Osipov edited comment on MPIR-278 at 8/24/13 11:32 AM:
---------------------------------------------------------------
Nicholas, I fully agree that algorithm and display is simply broken. Though, I
am not a native speaker, this column should first of all say "Current Time" and
nothing more. The values should be in ISO8601 format. One could argue whether
it is necessary to add tz information to the datetime stamp because the zone is
already indicated in the left-hand column.
Moment.js would be a perfect solution.
There are a few points which need to be considered:
1. Supplying a number instead of a TZ id may lead to shift during DST.
2. Do other devs agree with a third party dep and does the license permit
redistribution with ASL? Can we even add dependencies from a report? Do we
need to change the site.vm, etc.?
3. What happens when TZ information changes and the page is still up? Wrong
calculcation.
I would actually like to use Moment.js here and make that column optional
during the rendering phase. A dev can still enable it in the POM.
WDYT?
was (Author: michael-o):
Nicholas, I fully agree that algorithm and display is simply broken.
Though, I am not a native speaker, this column should first of all say "Current
Time" and nothing more. The values should be in ISO8601 format. One could argue
whether it is necessary to add tz information to the datetime stamp because the
zone is already indicated in the left-hand column.
Moment.js would be a perfect solution.
There are a few points which need to be considered:
1. Supplying a number instead of a TZ id may lead to shift during DST.
2. Do others devs agree with a third party dep and does the license permit
redistribution with ASL? Can we even add dependencies from a report? Do we
need to change the site.vm, etc.?
3. What happens then TZ information changes and the page is still up? Wrong
calculcation.
I would actually like to use Moment.js here and make that column optional
during the rendering phase. I dev can still enable it in the POM.
WDYT?
> 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 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
