Red Hat Bugzilla – Bug 489214
bugzilla shows wrong timezone across DST transitions
Last modified: 2013-07-02 23:21:12 EDT
Description of problem:
It appears that bugzilla incorrectly labels comments with the server's *current* timezone abbreviation,
not the time that the comments were actually generated. This would be tolerable if the abbrev matched the displayed time of day, but it doesn't.
Version-Release number of selected component (if applicable):
whatever's in production as of 3/8/09
Steps to Reproduce:
1. look at bug #488941, for example
2. all comments are shown as EDT, including those from before this morning's DST changeover
3. Since the actual *times* of the older comments are in fact shown in EST, this is simply wrong.
factually incorrect time-of-day information
either the zone abbreviation should be made to match the displayed time, or vice versa.
I base my assertion that the older timestamps are wrong on looking at the time of receipt of the
associated nagmails. The mails match the displayed time of day, which means that those times
of day are indeed EST not EDT.
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.
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,
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
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.
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
Whew, looks like it worked to me :)