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

[Steven Rostedt <srostedt@redhat.com>]

Keir Fraser wrote:
> On 17/1/07 15:50, "Steven Rostedt" <srostedt@redhat.com> 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