Re: [libvirt] [PATCHv2 1/4] util: new function virTimeLocalOffsetFromUTC

Laine Stump wrote: > Since there isn't a single libc API to get this value, this patch > supplies one which gets the value by grabbing current UTC, then > converting that into a struct tm with localtime_r(), then back to a > time_t using mktime; it again does the same operation, but using > gmtime_r() instead (for UTC). It then subtracts utc time from the > localtime, and finally adjusts if dst is set in the localtime timeinfo > (because for some reason mktime doesn't take that into account). > > This function should be POSIX-compliant, and is threadsafe, but not > async signal safe. If it was ever necessary to know this value in a > child process, we could cache it with a one-time init function when > libvirtd starts, then just supply the cached value, but that > complexity isn't needed for current usage. Appears it breaks virtimetest on FreeBSD: TEST: virtimetest 20) Test localtime offset for "VIR-00:30" ... OK 21) Test localtime offset for "VIR-01:30" ... OK 22) Test localtime offset for "VIR-00:30VID,0/00:00:00,366/23:59:59" ... FAILED 23) Test localtime offset for "VIR-02:30VID,0/00:00:00,366/23:59:59" ... FAILED 24) Test localtime offset for "VIR-02:30VID-04:30,0/00:00:00,366/23:59:59" ... FAILED 25) Test localtime offset for "VIR-12:00VID-13:00,0/00:00:00,366/23:59:59" ... FAILED 26) Test localtime offset for "VIR02:45VID00:45,0/00:00:00,366/23:59:59" ... FAILED 27) Test localtime offset for "VIR05:00VID04:00,0/00:00:00,366/23:59:59" ... FAILED 28) Test localtime offset for "VIR11:00VID10:00,0/00:00:00,366/23:59:59" ... FAILED My initial impression is that it's something wrong on the FreeBSD side, because date(1) doesn't respect TZs from failing tests, for example: $ date Sat May 31 23:15:45 MSK 2014 $ TZ=VIR-00:30 date Sat May 31 19:45:53 VIR 2014 $ TZ=VIR-00:30VID,0/00:00:00,366/23:59:59 date Sat May 31 19:15:58 UTC 2014 So it looks like it's failing back to the UTC time.