Bug 817709 - RFE: csprocessor revisions in local time
RFE: csprocessor revisions in local time
Status: CLOSED NOTABUG
Product: PressGang CCMS
Classification: Community
Component: CSProcessor (Show other bugs)
1.x
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lee Newson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-30 20:23 EDT by Joshua Wulf
Modified: 2014-10-19 19:00 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-18 09:49:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joshua Wulf 2012-04-30 20:23:56 EDT
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.




cspclient-0.23.1-1.noarch
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-04-30 20:56:40 EDT
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-04-30 22:01:46 EDT
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-04-30 22:06:54 EDT
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-04-30 22:11:28 EDT
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-04-30 22:29:05 EDT
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-04-30 22:34:30 EDT
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 09:49:41 EDT
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.