Here, the server show  "02:35:55 UTC", which look correct to me :

~ $ date
jeu. avril 14 16:47:29 CEST 2011
~ $ date -u
jeu. avril 14 14:47:32 UTC 2011

So maybe that's a issue with your setting ( or with mine ).

CC: (none) => misc

Michael Scherer 2011-04-14 18:48:16 CEST <-- that's in two hours.

Ok so there is something funky going on.
Does it happen :
- when you are not logged ?
- using a different browser  ?

I still do not see the issue using firefox and not being connected, yet I fail to see how this would changes something ( and yet, it does ).

If I'm logged out and viewing this bug, your last comment 3 has the timestamp 2011-04-14 16:54:19 UTC. This is unrelated to my browser as Bugzilla sets it server-side.

I see the same timestamp that Frederic does, and I'm in UTC-5:00 using firefox.  It is indeed coming from the server, as the page source shows:

        <span class="bz_comment_time">
          2011-04-14 16:54:19 UTC
        </span>

CC: (none) => ftg

Are Bugzilla and the DB server in the same timezone?

Same server, likely same timezone. I can restart both but I would prefer not.

The httpd server has less env vars thatn postgresql, yet there doesn't seems to have any issue related to timezone.

So that's set server side, but we do not have the same result. 

So just to be clear, the issue is on the web page, or on mail sent on the ml ? ( cause I have been looking at the web page, but maybe I misunderstood )

The issue is on the web page, yes. The Date: header in bugmails is correct.

What's the output of: SELECT LOCALTIMESTAMP(0) in PostgreSQL?

postgres=# SELECT LOCALTIMESTAMP(0);
      timestamp      
---------------------
 2011-04-14 18:00:54
(1 row)

using admin account.

bugs=> SELECT LOCALTIMESTAMP(0);
      timestamp      
---------------------
 2011-04-14 18:11:24
(1 row)

using bugzilla account

Really weird. I will have to look at the source code to guess what's wrong.

Per my discussion with misc on IRC, it appears that:

perl -MDateTime::TimeZone -we 'print DateTime::TimeZone->new(name => "local");'

executed from the command line returns DateTime::TimeZone::Europe::Paris, but the timezone user pref set to "Same as server" returns UTC, which doesn't make sense as they both call the same code. The only difference is that the first command is executed from the shell, as root, and the 2nd one is executed by the web server (Apache?). Unless it's possible for the web server to have the wrong timezone set, I have no idea what's wrong. So I give up! :)

[apache@alamut root]$ perl -MDateTime::TimeZone -we 'print DateTime::TimeZone->new(name => "local") . "\n";' ; id
DateTime::TimeZone::Europe::Paris=HASH(0x13f46b0)
uid=485(apache) gid=480(apache) groups=480(apache)

But maybe the process is running in a different env due to mod_perl ?

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

CC: (none) => remco

seems resolved, no ?

ah no sorry for the noise :)

Created attachment 683 [details]
screenshot

The timestamps varie when you reload the page several times. See the screenshot as an example, and note the timestamps on the left and on the right... misc, you installed a random number generator or what? :)

This happens both in anonymous mode (you) and authenticated (mine). And within several reloads, time goes CEST, then CEST+2, then back to CEST.

Is the page cached entirely or partially?

Seeing https://bugzilla.mozilla.org/show_bug.cgi?id=486255 this could be that the timestamp displayed is computed with two distinct (inconsistent) code paths, whether the page is loading from cache or from a fresh copy of the db? (just a guess)

Unrelated. Bug 486255 is about timestamps in emails sent via SMTP when you live in some "special" timezones.

At the moment I don't see a wrong timestamp, but I've seen it so recently that I don't think this got fixed.

Changing the summary to "The timestamp in Bugzilla comments can be wrong", because it is often right.

CC: (none) => marja11
Summary: The timestamp in Bugzilla comments is wrong => The timestamp in Bugzilla comments can be wrong

Pinging. because nothing happened to this report since more than 3 months ago, and it still has the status NEW or REOPENED.

Please set status to ASSIGNED. If for work flow reasons you can't do that, then please put OK on the whiteboard instead.

Seems to be ok now. Maybe that's due to the upgrade.

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED