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