On 12/06/2010 12:59 AM, Dan Kenigsberg wrote:
Humans consider January as month #1, while gmtime_r(3) calls it month
#0.
There's no question that struct tm is hideous. But we have to live with it.
While fixing it, render qemu's rtc parameter with leading zeros, as is more
commonplace.
Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=660194
---
src/qemu/qemu_conf.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 83c0f83..973e95b 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -3510,9 +3510,9 @@ qemuBuildClockArgStr(virDomainClockDefPtr def)
now += def->data.adjustment;
gmtime_r(&now, &nowbits);
- virBufferVSprintf(&buf, "base=%d-%d-%dT%d:%d:%d",
+ virBufferVSprintf(&buf, "base=%d-%d-%dT%02d:%02d:%02d",
This 0-pads the timestamp, but not the month and day. That is, come
next month, we should render Jan 2 as 2011-01-02.
nowbits.tm_year + 1900,
- nowbits.tm_mon,
+ nowbits.tm_mon + 1,
ACK with that nit fixed, and pushed.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org