Closed
Bug 67077
Opened 24 years ago
Closed 22 years ago
Bugzilla should display the time zone on all times
Categories
(Bugzilla :: User Interface, defect, P3)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: mozilla-linux, Assigned: jacob)
References
(Blocks 1 open bug)
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
justdave
:
review+
|
Details | Diff | Splinter Review |
The comments entered on a bug have a time stamp but it doesn't indicate the
timezone it is in.
Ideally, the user should be able to configure the time zone to their local time
zone so they can see the times in their local time. Regardless, the time zone
should be displayed so that users can accurately determine when the comment was
made.
Comment 2•24 years ago
|
||
2.16 for showing timezone somewhere, Future for user-specified timezone.
Target Milestone: --- → Bugzilla 2.16
Comment 3•24 years ago
|
||
Because comments aren't numbered, bugzilla users are currently forced to refer
to comments by date and time, and then other people Ctrl+F to find the comment
with that date and time. I think we should just add a "PST" after the time
instead of letting users specify which timezone they see dates in. After bug
71840 ([RFE] Make comments referencable using named anchors) has been fixed for
a while, we might consider user-specified timezones again.
Updated•23 years ago
|
Priority: -- → P3
Comment 4•23 years ago
|
||
-> Bugzilla product, currently User Interface component, reassigning.
Assignee: tara → myk
Component: Bugzilla → User Interface
Product: Webtools → Bugzilla
Version: other → unspecified
Comment 5•23 years ago
|
||
Bugzilla comments are now numbered. Given that, is it worth adding "PST" or
equivalent to all time instances throughout the product? Or is a global
announcement on the front page - "all times are PST" - enough?
Gerv
Comment 6•23 years ago
|
||
"All times are PST" is not a very friendly sentence to put on the front page of
a web site.
Comment 7•23 years ago
|
||
We are currently trying to wrap up Bugzilla 2.16. We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut. Thus this is being retargetted at 2.18. If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
It's not only the comments where the timezone is an issue. The bug opening
date/time doesn't show a timezone, and where the server is in a different zone
to the user the time shows does not match their local time - confusing if a
user in USA enters a bug on a server in UK and sees the opening time as 5 hours
ahead of their current time i.e. a time which hasn't happened yet (or vice
versa, they enter a bug from UK on a USA server and find it showing as opened 5
hours ago, and this is my situation). I'm just experimenting with adding the
GMT zone to all the time2str and str2time statements, and replacing all
instances of now() with (DATE_ADD(now(),INTERVAL 5 HOUR)) - it looks like it
will work but I haven't finished testing yet. Also adding GMT to the end of the
line showing opening and comment dates (bug_form.pl and globals.pl)
Comment 9•23 years ago
|
||
*** Bug 123352 has been marked as a duplicate of this bug. ***
Comment 10•23 years ago
|
||
*** Bug 124866 has been marked as a duplicate of this bug. ***
Comment 11•23 years ago
|
||
*** Bug 120162 has been marked as a duplicate of this bug. ***
Comment 12•22 years ago
|
||
It should not be GMT but UTC. Over 25 years ago (in early 1970's), it was
decided that UTC be used to indicate Universal Time Zone instead of GMT
even though BBC still prefers to use GMT ;-) and some misinformed implementation
of internet products use GMT where UTC should be used.
BTW, I think the best format for the timezone spec. is not using
ambiguous letter abbrebiation such as PST, BST, EST (except for UTC)
but the offset w.r.t UTC along with leeter abbr. in parentheses
if necessary (e.g. -0800 (PST), -0400 (EDT), 0900 (JST)).
Comment 13•22 years ago
|
||
I'd go further than the summary. Every time in Bugzilla (e.g., creation time,
times in bug activity) should have time. It is really annoying to guess which
time zone this refers to. I'd call this bug major not minor.
One real example. We just had a blocker bug (bug 173953). I am just trying to
find out if the time it was marked FIXED was before or after 1.2b release. Yes,
I know I could find out by other means, but looking at the time it was marked
FIXED is the most obvious and straigtforward way to do it.
pi
Comment 14•22 years ago
|
||
changing summary to match current discussion on this bug
Blocks: 176979
Summary: No time zone on bug comments → Bugzilla should display the time zone on all times
Comment 15•22 years ago
|
||
*** Bug 177088 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
The time stamp for creation of a bug is actually current time of the server the
MySQL DB runs on. Other time stamps displayed come from current time of the web
server, which are not always on the same box and might run on different time
zones even when on the same box:
I have one server with several Bugzilla installations for users around the
globe. I could probably individually fix the time zone value by setting the time
zone in CGI.pl somehow, but all bugs would have an "Opened" time which is the
timezone the MySQL DB is in.
My users don't like this at all.
Comment 17•22 years ago
|
||
All time should be from the db, though.
Comment 18•22 years ago
|
||
> The time stamp for creation of a bug is actually current time of the server
> the MySQL DB runs on. Other time stamps displayed come from current time of
> the web server, which are not always on the same box and might run on
> different time zones even when on the same box:
But surely they'd all be in UTC, and would be converted to the local time zone
for display purposes... and displaying the time zone is easily done; no doubt
you're familiar with strftime() and friends...
Assignee | ||
Comment 19•22 years ago
|
||
> The time stamp for creation of a bug is actually current time of the server
> the MySQL DB runs on. Other time stamps displayed come from current time of
> the web server, which are not always on the same box and might run on
> different time zones even when on the same box:
What times are computed by the webserver? AFAIK, all times are retrieved from
the database server.
-> me as I'm working on the easy part (appending the timezone to all displayed
times) that can later be expanded to do the hard stuff (adjusting the time based
on the user's prefered time zone).
Assignee: myk → jake
Assignee | ||
Comment 20•22 years ago
|
||
Assignee | ||
Updated•22 years ago
|
Attachment #107244 -
Flags: review?
Comment 21•22 years ago
|
||
Comment on attachment 107244 [details] [diff] [review]
Add timezone to the end of all displayed times
this is going to sound like a nit, but with the multi-database integration
coming down the pike, we need to continue to use DATE_FORMAT() on times coming
out of the database, because different databases return dates in different
formats and that's the only way we can guarantee that they all look alike.
Sybase, unfortunately, has a limited vocabulary for date formatting - it has a
list of 15 formats to pick from, I can't mix and match. And the closest I can
get to ISO is something that looks like "yyyy.mm.dd hh:mm:ss" (with dots in the
date part). So I'd recommend formatting all dates coming out of the database
with that format then changing them to what you want in your filter.
I think this filter will help a lot with the cross-DB compatibility if we do
that, BTW. Thanks!
Attachment #107244 -
Flags: review? → review-
Assignee | ||
Comment 22•22 years ago
|
||
Attachment #107244 -
Attachment is obsolete: true
Assignee | ||
Updated•22 years ago
|
Attachment #107265 -
Flags: review?(justdave)
Comment 23•22 years ago
|
||
Why are we not storing dates in the database as time_t (seconds since the epoch)
values, manipulating them as such, and then formatting them in templates? It
seems odd to format a date a particular way and then reformat it later.
See bug 162664 and friends for other discussions on dates and timezones.
Gerv
Comment 24•22 years ago
|
||
The core reason is because databases have the capability to perform various
operations on dates that can't be done easily on seconds... like the difference
between two dates in months, for example, which is not exactly easy on a time_t
because very few months have the same number of seconds in them.
On the other hand, is there anywhere in Bugzilla where we're measuring dates in
any way other than days? Is there a reason we need to be able to measure in
months? Are we shooting ourselves if we eliminate that possibility?
Comment 25•22 years ago
|
||
Ref. comment 24:
Oh good, a strawman shoot :-)
You can use gmtime() or localtime() to convert from time_t to struct tm, and
month calculations become nice and easy.
Few months have the same length? (I'm assuming UTC or at least no seasonal
timezone changes and I'm ignoring leap seconds.) I'm finding it hard to see
anything other than do I see seven months of one length, four of another, and
one with two lengths where which is used is determined mathematically?
Comment 26•22 years ago
|
||
gerv: I agree. It appeas that sybase has no way to do that, though.
Ideally, we'd receive seconds-since-epoch, and then format in the template, but....
Comment 27•22 years ago
|
||
We could always format all the timestamps as integers in the database and
convert them to/from dates/times in Perl. This would get around some of the
timezone problems some databases have, since str2time and time2str can deal with
timezones...
Comment 28•22 years ago
|
||
Comment on attachment 107265 [details] [diff] [review]
Patch v2: Use DATE_FORMAT when retrieving times
You need to fix the grammar in your pod text in Bugzilla::Util before checking
it in.
Attachment #107265 -
Flags: review?(justdave) → review+
Assignee | ||
Comment 29•22 years ago
|
||
I can't say that I really like the DATE_FORMAT part of the patch, but the most
important part is getting the |FORMAT time| into all the places it needs to be.
Bug 182238 filed for the next logical step in this progression.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 30•22 years ago
|
||
This has created a circular dependancy between Bugzilla::Util and
Bugzilla::Config. This is why you needed to use &::Param - we havne't reached
the EXPORT line when thats brought it. Thats bad.
I guess that bug 182238 will fix this, since it won't be a Param, but raher an
attribute on teh current user. You'll still need a default, though, I think.
I don't have a good fix for this - whats the timeframe on bug 182238?
(A hacky fix is to call Bugzilla::Config::Param manually, after requiring it in
teh sub. I'll do that if I get to mod_perl'ing show_bug before this is fixed,
since it doesn't really matter until then)
Comment 31•22 years ago
|
||
Excuse me, just to keep in mind,
http://www.bipm.org/enus/5_Scientific/c_time/time_server.html
and
http://www.cl.cam.ac.uk/~mgk25/iso-time.html
Comment 32•22 years ago
|
||
*** Bug 194192 has been marked as a duplicate of this bug. ***
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•