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

[Laine Stump]

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