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.

Good idea, I'd like that, too.

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

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.

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

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

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

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.

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)

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

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

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

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

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

changing summary to match current discussion on this bug

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

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.

All time should be from the db, though.

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

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

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

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?

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?

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

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

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.

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)

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

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