Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 817709 - RFE: csprocessor revisions in local time
Summary: RFE: csprocessor revisions in local time
Alias: None
Product: PressGang CCMS
Classification: Community
Component: CSProcessor
Version: 1.x
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Lee Newson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2012-05-01 00:23 UTC by Joshua Wulf
Modified: 2014-10-19 23:00 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-05-18 13:49:41 UTC

Attachments (Terms of Use)

Description Joshua Wulf 2012-05-01 00:23:56 UTC
Can we  have 

csprocessor revisions

return the list with the times adjusted from the server timezone to the timezone of the local client. 

So the client would check the local time zone, then apply the adjustment to the server-provided times, then display.

OS: Fedora release 16 (Verne)

JAVA: java version "1.7.0_b147-icedtea"
OpenJDK Runtime Environment (fedora-2.1.fc16.1-x86_64)
OpenJDK 64-Bit Server VM (build 22.0-b10, mixed mode)

Comment 1 Lee Newson 2012-05-01 00:56:40 UTC
That won't work in this instance as the time is incorrect on the server. If I were to adjust it then the times would be ahead 18hrs rather then the four they are atm.

Though this is a good idea but won't fix the issue that brought up this RFE.

Comment 2 Joshua Wulf 2012-05-01 02:01:46 UTC
Correct is a relative term. If the server time is 4 hours ahead of Brisbane then the adjustment to report local time for GMT +10 (Brisbane) is -4.

Comment 3 Joshua Wulf 2012-05-01 02:06:54 UTC
To make it future proof and portable you'd query the server time zone, if it were possible, and calculate the difference, rather than hardcode an assumption about where the server is located / how it is configured.

I'm deploying an instance for Fedora on a server located in the US, and I'd like to see times that are local for me. Doing all those time-shifting calculations for bugzilla drives me nuts....

Comment 4 Lee Newson 2012-05-01 02:11:28 UTC
And that's the issue which is why i said it wouldn't work. The server timezone is currently set to EST which i believe is -4GMT but currently its 4hours ahead of us.

To fix this you first have to fix the server but as I mentioned earlier I'm not sure if its possible as it may corrupt the database. So that's something that needs to be looked into first.

Comment 5 Joshua Wulf 2012-05-01 02:29:05 UTC
well yeah, if the server time is set wrong then it's set wrong, but that's a different issue....

the RFE is to adjust the csprocessor revision output to match the local time zone. I'm travelling across a few time zones in May and June, so it will be useful to me then; but I can see also that it will be useful for people who are using the content spec processor and aren't in the same time zone as the server they are using - like peeps in Brno using a server in Brisbane, or anyone in Fedora land anywhere in the world other than the place where the server is.

A lower-cost alternative would be to report the server timezone (and maybe the current time on the server to hedge against it being set wrong), when reporting the csprocessor revisions, and let the user do the math.

Comment 6 Lee Newson 2012-05-01 02:34:30 UTC
And i'm aware of that hence the second part to my first comment. I just wanted to make it 100% clear of the repercussions of implementing this since I was aware of where this RFE came from.

Comment 7 Lee Newson 2012-05-18 13:49:41 UTC
Looked into this and the times are already being converted to the correct time zone since the output is constructed using the SimpleDataFormat class. This class defaults to the local machine Time Zone when none is set, so therefore this was already happening and the only issue is that the server time is incorrect.

Note You need to log in before you can comment on or make changes to this bug.