[Top][All Lists]

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

Re: [Qemu-devel] [RFC] Can we convert UTC time to local time in Qemu

From: Gonglei
Subject: Re: [Qemu-devel] [RFC] Can we convert UTC time to local time in Qemu
Date: Thu, 21 May 2015 10:10:31 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0

On 2015/5/20 22:43, Eric Blake wrote:
> On 05/20/2015 12:29 AM, Gonglei (Arei) wrote:
>> Hi,
>> At present, Qemu use g_time_val_to_iso8601() to get the UTC added to 
>> error_report()
>> (commit 5e2ac5191), TBH this way is very simply, we just need invoke 
>> standard glib functions to
>> complete the job. 
> local time is ambiguous (daylight savings, and even consider what
> happens when you physically relocate your machine to a different time
> zone).  UTC is better.
Actually this is a scenario that happen unlikely. :(
>> But in the cloud computing and data center scenarios, there are many
>> Other open source components, such as kernel, libvirt, openstack which are 
>> all using local time
>> to record the message logs, only Qemu is using the UTC time. When we want to 
>> find a error
>> message of Qemu, we should convert the UTC time to local time manually, and 
>> unfortunately
>> different countries have different local time, what a trouble thing the 
>> converting is.
>> So, my question is: Can we convert the UTC time to local time in Qemu? 
> Actually, libvirt uses UTC on purpose, not only because it is
> unambiguous, but because it prints timestamps even in situations where
> it must be async-signal safe, and there is no async-signal-safe way to
> determine the offset required to convert UTC to local time.
Yes, I got it.
>> Any thoughts? Thanks.
> I'd rather stick with UTC in logs (but perhaps make it more obvious that
> the timestamp is UTC by actually sticking that string as part of the
> timestamp - libvirt is not currently doing that).
OK, I agree, will post a patch to Qemu maillist.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]