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. Roman Bogorodskiy