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

[Laine Stump]

On 05/23/2014 03:47 PM, Eric Blake wrote:
> On 05/23/2014 05:43 AM, Laine Stump wrote:
>
>>> man tzset:
>>>
>>>        The second format is used when there is daylight saving time:
>>>
>>>               std offset dst [offset],start[/time],end[/time]
>> Aha! And combining that with the "VIR" timezone idea that we're already
>> using, I've found that the following string *does* set DST:
>>
>> TZ="VIR02:30VID,0,365"
>>
> That probably still has a window where running 'make check' on Dec 31
> may fail; maybe using the time argument as in /23:59 will minimize the
> window to one minute?

Ah, right - because that is the *end* day. I just tried this in a
virtual machine:

declare -x TZ="VIR00:30VID,0,366
date --set "Dec 31 2012 23:59:57"   (2012 is a leap year)

The output of date showed "VID" (i.e. DST is in effect), and it
continued to show VID right through midnight.

>> while the following *doesn't* (at least not today :-):
>>
>> TZ="VIR02:30VID,300,365"
>>
>> So I can add the former as a test case.
> It's awkward testing for daylight savings cases if the test is dependent
> on today's date; hopefully whatever you come up with is sufficiently
> isolated that it doesn't introduce spurious failures on certain days of
> the year.

I think the above  does that.

>
> Also, if I understand correctly, once you have a TZ with daylight
> savings rules, the tm_isdst of struct tm can be set to negative to use
> the TZ rules for determining if it is in effect, to 0 to force the
> standard time (even if the current time is during dst) and to 1 to force
> the daylight time (even if the current time is during std).  (And that
> this is true for tm_isdst, but NOT for the global 'daylight', which is
> merely specified as positive year-round if TZ includes daylight rules).
>

Since the existence of tm_isdst is transparent to the caller of
virTimeLocallOffsetFromUTC, we can't use that for testing purposes. And
from the point of view of the function itself, I'd rather not manipulate
that value if I don't have to - I'd rather leave as much to the system
as possible, and just detect it with the test on systems that might
behave differently - then we can fix it if necessary.