Feature #4401
Chart dates should use same timezone as server
| Status: | Closed | Start date: | 07/30/2010 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | 1.1.0 | |||
| Keywords: | roadmapped | Affected URL: | ||
| Branch: | Affected Dashboard version: | |||
| Votes: | 0 |
Description
Currently, the charts displayed using the browser’s timezone, while the rest of the dates are rendered using the server’s timezone — which usually aren’t the same.
Related issues
History
Updated by Jeff McCune almost 2 years ago
Updated information:
In version 1.0.3, the charts displayed appear to be in UTC or GMT or something entirely different. I’m running dashboard through webrick on a CentOS 5.5 system set in the same timezone as my mac workstation and the times associated with the reports appear way off.
I’ll attach screen captures if you’d like.
-Jeff
Updated by Igal Koshevoy almost 2 years ago
- Target version changed from 61 to 1.0.5
Issue #4403 and its minimalist solution affect this.
Updated by Nick Lewis over 1 year ago
The charts appear to already be rendering with the timezone set in the server’s config/environment.rb. Is this the desired behavior, or should it be the actual timezone in which the server is located?
Updated by Nick Lewis over 1 year ago
- Status changed from Accepted to Needs More Information
- Assignee set to Igal Koshevoy
Updated by Oliver Hookins over 1 year ago
I notice that the list of recent reports on the frontpage, and in recently failed nodes / no longer reporting nodes are in UTC which is in environment.rb. Then, if I select a single node, all of the reports in the list are displayed also in UTC, but if I drill down into a single reports for this node, the log line timestamps are in CEST. I can’t say if this is coming from my browser, the server’s timezone or somewhere else though.
Updated by Igal Koshevoy over 1 year ago
- Assignee deleted (
Igal Koshevoy)
Oliver: Thank you for reporting this problem and giving us an example of the location where we could find the wrong value. I’ve created bug #4794 and pushed a fix for it.
Updated by Nigel Kersten over 1 year ago
- Keywords set to roadmapped
Updated by Jesse Wolfe over 1 year ago
- Status changed from Needs More Information to Closed
Merged into next in commit:5acb5b260ddbd7d16edcae1fde6eff5f50a7b111
Merged into master in commit:4c484f2a6a6f627d4b8926404ca179ed373cb9cc as part of Iteration-2010-11-17
Updated by James Turnbull about 1 year ago
- Target version changed from 1.0.5 to 1.1.0