Alexander Koblov wrote:
Why tzdata-2014g returns timezone for the Europe/Moscow -10800 (3 hours)? As far as I understand timezone for Moscow should be changed on the night of 25/26 October.
Thanks for reporting the problem. It is a bit confusing here. When tzset is called, it does not know what time stamps you are interested in. It guesses, and its guess is based on time stamps that are farthest in the future. Here, tzcode's tzset behaves like the GNU C library and (I expect) like many other libraries. Since tzset is not required to prefer any particular time stamps, its behavior appears to be "correct", in the sense that it conforms to the standard and is reasonable for some applications (though evidently not for yours...). If you have a need for the UTC offset I suggest using the tm_gmtoff member of 'struct tm' if available, as tm_gmtoff is more reliable than 'timezone'. While looking into this issue I noticed a related problem: if your platform lacks tm_gmtoff and you are using single-threaded code, the 'timezone' variable should work better than it does. 'timezone' and 'altzone' should be compatible with what's in 'tzname', but in 2014h sometimes they are not. The attached proposed patch should fix that. This patch won't fix your test case, but it should fix some similar cases based on code that invokes 'localtime' or 'mktime' and which then inspects 'timezone' or 'altzone'. (This is not thread-safe, of course; multithreaded programs should use tm_gmtoff.)