Bug 489214
Summary: | bugzilla shows wrong timezone across DST transitions | ||
---|---|---|---|
Product: | [Community] Bugzilla | Reporter: | Tom Lane <tgl> |
Component: | User Interface | Assignee: | PnT DevOps Devs <hss-ied-bugs> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 3.4 | CC: | bashton, dnorthup, hhorak |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-01-22 20:48:14 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Tom Lane
2009-03-08 17:22:58 UTC
Is there a reason the bz server(s) cannot be put on UTC and we can all just forget about this nonsense. This seems like the right thing to do in the long run anyway. (In reply to comment #1) > Is there a reason the bz server(s) cannot be put on UTC and we can all just > forget about this nonsense. This seems like the right thing to do in the long > run anyway. I suspect that it wouldn't matter if the server is/isn't itself on UTC time as the way that the time is displayed is typically independent of the "hardware" time of the hosting machine. This looks like a presentation layer problem, it is still there several months later, and it is annoying. Please try our new beta version of Bugzilla. With the new version, the user can set their own timezone in the userprefs.cgi screen and then all dates/times will be adjusted to display in the timezone calculated from the server's timezone. Dave Red Hat Bugzilla is now using version 3.4 of the Bugzilla codebase and therefore this bug will need to be re-verified against the new release. With the updated code this bug may no longer be relevant or may have been fixed in the new code. Updating bug version to 3.4. I see that the current version shows 'EST' or 'EDT' for different comments in a way that seems to relate to the time of year, so this may well work correctly now. It'll be difficult to be really sure until the next DST change in March, though. (In reply to comment #5) > I see that the current version shows 'EST' or 'EDT' for different comments in a > way that seems to relate to the time of year, so this may well work correctly > now. It'll be difficult to be really sure until the next DST change in March, > though. Yes the newer bugzilla now allows users to configure their own timezones to display the date information. We can leave this bug open for now if you want to see what happens in March, or just close it as CURRENTRELEASE and we can reopen it in march if needed (or open new one). Thanks for verifying Dave I put an entry in my calendar to remind me to recheck in March. If you'd like to get this out of your face for now, feel free to close it. I'll reopen if I see a problem. Thanks this comment added at 12:47 EDT local time ... if it shows up that way, all is well. (In reply to comment #9) > this comment added at 12:47 EDT local time ... if it shows up that way, all is > well. Whew, looks like it worked to me :) |