67077 - Bugzilla should display the time zone on all times

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect, P3)

Description

[Stephen Rasku]

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 1

[Stephan Niemz]

Good idea, I'd like that, too.

Comment 2

[Matthew Tuck [:CodeMachine]]

2.16 for showing timezone somewhere, Future for user-specified timezone.

Comment 3

[Jesse Ruderman]

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.

Comment 4

[Andreas Franke (gone)]

-> Bugzilla product, currently User Interface component, reassigning.

Comment 5

[Gervase Markham [:gerv]]

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

[Jesse Ruderman]

"All times are PST" is not a very friendly sentence to put on the front page of 
a web site.

Comment 7

[Dave Miller [:justdave]]

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.

Comment 8

[simona]

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

[Herbert Thielen]

*** Bug 123352 has been marked as a duplicate of this bug. ***

Comment 10

[timeless]

*** Bug 124866 has been marked as a duplicate of this bug. ***

Comment 11

[xyzzy]

*** Bug 120162 has been marked as a duplicate of this bug. ***

Comment 12

[Jungshik Shin]

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

[Boris 'pi' Piwinger]

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

[Dave Miller [:justdave]]

changing summary to match current discussion on this bug

Comment 15

[Dave Miller [:justdave]]

*** Bug 177088 has been marked as a duplicate of this bug. ***

Comment 16

[Arne Schirmacher]

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

[Bradley Baetz (:bbaetz)]

All time should be from the db, though.

Comment 18

[Darren Salt]

> 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...

Comment 19

[Jacob Steenhagen]

> 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).

Comment 20

[Jacob Steenhagen]

Attachment: Add timezone to the end of all displayed times

Comment 21

[Dave Miller [:justdave]]

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!

Comment 22

[Jacob Steenhagen]

Attachment: Patch v2: Use DATE_FORMAT when retrieving times

Comment 23

[Gervase Markham [:gerv]]

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

[Dave Miller [:justdave]]

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

[Darren Salt]

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

[Bradley Baetz (:bbaetz)]

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

[Dave Miller [:justdave]]

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

[Dave Miller [:justdave]]

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.

Comment 29

[Jacob Steenhagen]

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.

Comment 30

[Bradley Baetz (:bbaetz)]

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

[opmolf]

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

[Dave Miller [:justdave]]

*** Bug 194192 has been marked as a duplicate of this bug. ***