On 05/31/2014 11:11 PM, Roman Bogorodskiy wrote:
Roman Bogorodskiy wrote:
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. After some more experiments I noticed that changing 366 to 365 makes it work:
$ TZ=VIR-00:30VID,0/00:00:00,365/23:59:59 date Sat May 31 21:34:25 VID 2014 $
And also changing that in the test makes it pass.
Sigh. Yeah, I made it 366 in an attempt to force DST to be always active, and it didn't seem to have any adverse side effects. In the meantime I ended up making most of the DST tests not run on Dec 31 / Jan 1 anyway, but never changed the end day because it wasn't causing harm. I just made that change locally and did a short test that ran successfully. If anything, it *could* cause a failure of the few DST tests that are left enabled all year, but only at the end of the year. Since the release of 1.2.5 is imminent, I've pushed the patch as a buil breaker.
Looking at this document:
http://pubs.opengroup.org/onlinepubs/9699919799/
It describes TZ environment variable format and says about the days that it should be:
0 <= n <= 365
I haven't yet found what should happen when the format given in TZ environment variable doesn't follow the format.
Roman Bogorodskiy