[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Have xen dom0 still handle time of 1970



Keir Fraser wrote:
On 17/1/07 15:50, "Steven Rostedt" <srostedt@xxxxxxxxxx> wrote:

Here's what you get without the patch:

# date -u 010100011970
Thu Jan  1 00:01:00 UTC 1970
# date
Mon Feb 22 16:42:30 EST 2010

Here's what you get with the patch:

# date -u 010100011970
Thu Jan  1 00:01:00 UTC 1970
# date
Wed Dec 31 19:01:01 EST 1969

The Xen interface is defined relative to UTC, not local time zone, so
negative numbers shuld not be involved if you are setting a time value after
the epoch (which you are). Perhaps our assumption that xtime is a UTC
variable is broken? If that's the case, is there a way to translate between
local time zone and UTC inside the kernel? If not we have a bit of a problem
since it really makes sense for Xen to work in UTC and let each guest apply
its own time-zone transformation.


It doesn't matter about the TZ. If I do this on a machine that has been running xen for more than a day, it will still fail with setting date to

date -u 010123001970

Which is not effected by the TZ (the result is after EPOCH).

The problem is that the calculation uses the uptime and compares that with the given time past EPOCH (using UTC). So if that time is less than uptime, it will fail the time conversion.

Have a box with Xen running more than a day? (I currently don't), and if you do, try the above date command. You'll see what I'm talking about.

The example is bad, but I didn't have a machine to show that has been running a Xen kernel for more than an hour or two.

-- Steve


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.