When setting hardware clock on linux guest, hwclock shows crazy date (in the year 2043)

[Lucas Meneghel Rodrigues]

Very easy to reproduce:

1) Build the latest qemu.git (we've captured this on internal automated testing, verified manually), the commit for reference is:

14:07:02 INFO | git commit ID is 6f8fd2530e9a530f237240daf1c981fa5df7f978 (tag v1.2.0-461-g6f8fd25)

2) Install a linux guest in it (caught with RHEL 6.2, verified with Fedora 17)

3) In the linux guest, set the hardware clock with hwclock:

/sbin/hwclock --set --date "2/2/80 03:04:00"

4) Verify if hardware clock was set back to the eighties:

LC_ALL=C /sbin/hwclock

5) Observe amazed that hwclock reports a date in the year 2043:

14:09:34 INFO | ('hwclock', 'FAIL', 2, "Failed to set hwclock back to the eighties. Output of hwclock is 'Sun Dec 27 20:35:46 2043 -0.489664 seconds'")

[Lucas Meneghel Rodrigues (lmr)]

Paolo fixed the problem with upstream commit:

commit b6db4aca20e9af4f62c9c9e08b9b9672a6ed3390
Author: Paolo Bonzini <email address hidden>
Date: Mon Oct 1 14:22:06 2012 +0200

    rtc: fix overflow in mktimegm

    When setting a date in 1980, Linux is actually disregarding the century
    byte and setting the year to 2080. This causes a year-2038 overflow
    in mktimegm. Fix this by doing the days-to-seconds computation in
    64-bit math.

    Reported-by: Lucas Meneghel Rodrigues <email address hidden>
    Signed-off-by: Paolo Bonzini <email address hidden>
    Signed-off-by: Anthony Liguori <email address hidden>

Confirmed that problem is solved. Closing bug.