On 05/28/2014 04:46 AM, Laine Stump wrote:
The original version of virTimeLocalOffsetFromUTC() would fail for
certain times of the day if daylight savings time was active. This
could most easily be seen by uncommenting the TEST_LOCALOFFSET() cases
that include a DST setting.
src/util/virtime.c | 3 +++
tests/virtimetest.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 56 insertions(+), 8 deletions(-)
diff --git a/src/util/virtime.c b/src/util/virtime.c
index 3a56400..c69dff1 100644
--- a/src/util/virtime.c
+++ b/src/util/virtime.c
@@ -377,6 +377,9 @@ virTimeLocalOffsetFromUTC(long *offset)
return -1;
}
+ /* tell mktime to figure out itself whether or not DST is in effect */
+ gmtimeinfo.tm_isdst = -1;
As pointed out by Wangrui, you also need to fix the bogus reference to
localtime_r() in the comments at the start of the function.
ACK with that change; worth having in 1.2.5. The rest of what follows
is up to you if you ignore it.
+
+/* return true if the date is Jan 1 or Dec 31 (localtime) */
+static bool
+IsJan1OrDec31(void)
Function names are usually camelCase, not StudlyCaps (s/Is/is/).
Bikeshedding: maybe name it isNearYearEnd()?
+
+ if (!IsJan1OrDec31()) {
+ /* experiments have shown that the following tests will fail
+ * during certain hours of Dec 31 or Jan 1 (depending on the
+ * TZ setting in the shell running the test, but in general
+ * for a period that apparently starts at 00:00:00 UTC Jan 1
+ * and continues for 1 - 2 hours). We've determined this is
+ * due to our inability to specify a timezone with DST on/off
+ * settings that make it truly *always* on DST - i.e. it is a
+ * failing of the test data, *not* of the function we are
+ * testing. So to test as much as possible, we still run these
+ * tests, except on Dec 31 and Jan 1.
Awesome comment; thanks :)
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org