[Bug time/23859] New: tzname, daylight are modified by localtime() in unexpected way

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug time/23859] New: tzname, daylight are modified by localtime() in unexpected way

cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23859

            Bug ID: 23859
           Summary: tzname, daylight are modified by localtime() in
                    unexpected way
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: time
          Assignee: unassigned at sourceware dot org
          Reporter: izbyshev at ispras dot ru
  Target Milestone: ---

Created attachment 11376
  --> https://sourceware.org/bugzilla/attachment.cgi?id=11376&action=edit
Demostrator of strange localtime() behavior

If I understand localtime() docs correctly, it should behave as if it calls
tzset() internally. However, I've discovered that it rather behaves as if it
unwinds time to the time_t it receives and only then calls tzset(). Moreover,
after it does so, calling tzset() explicitly doesn't restore globals like
'tzname' to the expected state.

I've attached the test case which tests localtime() with two timezones, both of
which are notable for changing their DST rules over time. The test sets TZ
environment variable, but I've verified that behavior is the same if
'/etc/localtime' is set appropriately and TZ is unset instead. The behavior is
also the same on (e)glibc-2.19 from Ubuntu 14.04 as well as on the current
trunk I've built myself (fc1c7bdc6). Below is the annotated output of the test
case.

At start:
GMT GMT 0 0
=== Testing Europe/Moscow ===
After first tzset():
MSK MSD -10800 1 # Why MSD? There is no DST since 2011.
Roughly current time; no DST in MSK since 2011:
2018-11-1 dst: 0 tz: MSK
MSK MSK -10800 0 # Looks like what the first tzset() should have been done. Or
should tzname[1] be empty?
Standard time, but DST is still observed in summer:
2009-11-1 dst: 0 tz: MSK
MSK MSD -10800 1 # Changed back to values correct for 2009.
DST:
2009-7-1 dst: 1 tz: MSD
MSK MSD -10800 1
Old TZ name for what is MSK now:
1991-7-1 dst: 1 tz: EEST
EET EEST -10800 1
After last tzset():
EET EEST -10800 1 # Even explicit tzset() doesn't restore the values
=== Testing America/Argentina/Buenos_Aires ===
After first tzset():
-03 -02 10800 1
No DST since 1994:
1995-11-1 dst: 0 tz: -03
-03 -03 10800 1
DST:
1990-11-1 dst: 1 tz: -02
-03 -02 10800 1
No DST:
1990-7-1 dst: 0 tz: -03
-03 -02 10800 1
Different UTC offset:
1960-7-1 dst: 1 tz: -03
-04 -03 10800 1 # OK, localtime() changes globals, but why is timezone still
10800 for -04?
After last tzset():
-04 -03 10800 1

I feel like either I totally misunderstood localtime() and tszet() docs or the
output above demonstrates a bug or several. I'd expect that tzname, timezone
and daylight stay the same between changes in TZ or /etc/localtime.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug time/23859] tzname, daylight are modified by localtime() in unexpected way

cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23859

--- Comment #1 from Alexey Izbyshev <izbyshev at ispras dot ru> ---
I've built my test with musl 1.1.16. The output is below. It matches my
understanding of the correct localtime() behavior.

At start:
(null) (null) 0 0
=== Testing Europe/Moscow ===
After first tzset():
MSK  -10800 0
Roughly current time; no DST in MSK since 2011:
2018-11-1 dst: 0 tz: MSK
MSK  -10800 0
Standard time, but DST is still observed in summer:
2009-11-1 dst: 0 tz: MSK
MSK  -10800 0
DST:
2009-7-1 dst: 1 tz: MSD
MSK  -10800 0
Old TZ name for what is MSK now:
1991-7-1 dst: 1 tz: EEST
MSK  -10800 0
After last tzset():
MSK  -10800 0
=== Testing America/Argentina/Buenos_Aires ===
After first tzset():
-03  10800 0
No DST since 1994:
1995-11-1 dst: 0 tz: -03
-03  10800 0
DST:
1990-11-1 dst: 1 tz: -02
-03  10800 0
No DST:
1990-7-1 dst: 0 tz: -03
-03  10800 0
Different UTC offset:
1960-7-1 dst: 1 tz: -03
-03  10800 0
After last tzset():
-03  10800 0

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug time/23859] tzname, daylight are modified by localtime() in unexpected way

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23859

--- Comment #2 from Andreas Schwab <[hidden email]> ---
If there is no DST then the value of tzname[1] is not used, thus doesn't
matter.

--
You are receiving this mail because:
You are on the CC list for the bug.
Reply | Threaded
Open this post in threaded view
|

[Bug time/23859] tzname, daylight are modified by localtime() in unexpected way

cvs-commit at gcc dot gnu.org
In reply to this post by cvs-commit at gcc dot gnu.org
https://sourceware.org/bugzilla/show_bug.cgi?id=23859

--- Comment #3 from Andreas Schwab <[hidden email]> ---
The specification for daylight and timezone are ambigous for time zones with
changing rules.  POSIX really only specifies the behaviour of POSIX style
values for TZ, which cannot change over time.

--
You are receiving this mail because:
You are on the CC list for the bug.