Bug 249857

It appears that the bug reporting system has allocated a low priority to this.

Given that the system is totally useless as is and therefore cannot be used, I
would say the priority is maximum.            Peter

Same here

I've been seeing the same issue on my machine, along with several other errors.
The weird thing is that when I opened a shell and typed "date" it gave me the
correct date, but in the GNOME clock and gaim, etc. it was completely frozen.
When I reboot to the old kernel I don't see a problem.

Same problem here. Even the following simple program shows the problem:
#include <stdio.h>
#include <time.h>

int main (int argc, char *argv[])
{
    time_t now = time(NULL);

    puts(ctime(&now));

    return 0;
}

Output is always:
$ ./ctime 
Sat Jul 28 00:44:40 2007
$ date
Fri Jul 27 23:29:39 CEST 2007

The test program always displays the same time. I'll let you know what happens
when the real time reaches the wrong time in 1h15 minutes. :-)

Same here, neither gdm nor xfce panel are able to show the correct time. Trying
to adjust xfce's date/time panel leads to complete lockup. Also logout from
desktop session results in text mode sinc X doesn't restart. Affected kernel is
2.6.22.1-33, while 2.6.22.1-27 just works fine.

Well, now that 'real time' has caught up with the 'fake time', the problem has
gone away:

$ ./ctime && date
Sat Jul 28 00:48:59 2007

Sat Jul 28 00:48:59 CEST 2007

I also had the X restart problem, which has now also gone away.

Ah, now I see some logic.  Looks like the system is adding the difference
between Greenwich mean time and my location time (Perth in Australia)twice,
rather than once.
My stopped clock is plus 16h exactly on GMT and should only be plus 8h.
After that trying to log out simply fires confusion as system cannot cope
adequately with a time in the future: indeed error message says "that should not
happen"

Same problem here ...
I wrote a little C-programm. The functions ctime, time and localtime do not work
correct.

ctime and time always give back the time when the kernel was started and
localtime always gives back UTC-time (does not resprct the time zone).

This kernel (2.6.22.1-33.fc7) is not usable at all with this bug.

Back to 2.6.21-1.3228.fc7 (the last usable kernel for me).

I was also knocked by the same issue.
According to my research, with "2.6.22.1-33", a clock of GNOME Desktop displays
wrong time, but NTP works well and returns me correct time(example,
"system-config-date" shows me correct time). 

So, I am useing 2.6.21.1-3228; the kernel that don't switch off ATA-HDD before
shutdown on my environment...

I have the same Problem.
date shows the right time, the gnome clock stays at the same time, even the
timestamps in syslog don't proceed. They show the time I turned on the computer
+2h (my timezone is utc+1+daylight savings). my hw clock is set to my localtime,
not to utc

It seems that KDE doesn't suffer of the bug...
Firefox neither (some JavaScript code to display time worked)...
The only workaround for now is to use kernel-2.6.22.1-27.fc7

Tools like "make" complain heavily (as they depend on the correct
time and date), and gkrellm's time display is also confused.

After boot, the time is wrong for the current GMT offset
(my computer runs at GMT +0200, and the new kernel adds
additional two hours). The time seems to go better if I
wait that amount of time (two hours).

The new kernel is unusable. On the other hand, I'm pretty sure
that some people may not notice the problm at all if they don't
do anything that depends on correct time and date.

I'm wondering that the "Priority" field of this bug is set to "low".
Nowadays, wrong time and date can result in very nasty things.

kernel 2.6.22.1-41.fc7 from here
http://koji.fedoraproject.org/koji/buildinfo?buildID=12174 resolved this bug

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

WFM

When would this kernel be pushed to update repository?

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

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

I guess this kernel had default priority, changing to "urgent". I agree
2.6.22.1-33.fc7 is not usable.

My symptom was a broken xchat, so it was difficult to ask for help.It took me 2
hours experimenting with all kinds of things before I suspected the kernel.

Both kernel -27.fc7 and the kernel from comment 13 work for me.

(In reply to comment #19)
> I guess this kernel 
... bug, not kernel

FYI, my XFCE showed a broken time, too, but this was the first time I tried
xfce, so I suspected a bug in xfce rather than the kernel

Same problem too.
The best workaround is to remove kernel 1-33. Temporary workaround could be to
"legalize" this time difference by changing localtime to UTC (/etc/sysconfig/clock)

Another problem with time:
[user@compy]# dmesg | grep Date
Time: 18:50:47  Date: 06/30/107
(it's current time and day)
What this Date mean?

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

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

Kernel from comment 13 works and also fixes bug #249950 for me.

Related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249857#c16 and
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250003 (also a major issue)
perhaps as an intermediate solution, imho a kernel rollback should be made
(using EPOCH), if pushing a fixed kernel from testing to update needs some more
time.

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

I guess this bug can be marked resolved currentrelease, because I can see the
updated kernel package in the f-7 updates download area, and it fixes the bug
for me.

Please comment or reopen the bug if you still have the problem.

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