[libvirt] [PATCH] Fix funny off-by-one error in clock-variable
Humans consider January as month #1, while gmtime_r(3) calls it month #0. 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", nowbits.tm_year + 1900, - nowbits.tm_mon, + nowbits.tm_mon + 1, nowbits.tm_mday, nowbits.tm_hour, nowbits.tm_min, -- 1.7.3.2
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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
participants (2)
-
Dan Kenigsberg -
Eric Blake