Created attachment 874734 [details] Reproducer for this bug. Description of problem: "... The array tzname contains two strings, which are the standard names of the pair of time zones (standard and Daylight Saving) that the user has selected. tzname[0] is the name of the standard time zone (for example, "EST"), and tzname[1] is the name for the time zone when Daylight Saving Time is in use (for example, "EDT"). These correspond to the std and dst strings (respectively) from the TZ environment variable. If Daylight Saving Time is never used, tzname[1] is the empty string." [1] As per the description above tzname[1] entry must be empty when DST is not used, ie. daylight=0. But instead it is set to the standard time zone, same as tzname[0]. It is problematic if a user has to set the TZ variable to: <tzname[0]><[+-]timezone><tzname[1]>, say TZ="EST-5:00EDT" This definition is valid because EST does follow daylight saving time. But TZ="IST-5:30IST" is an invalid definition, which affects working of other time.h functions like localtime(3), ctime(3) etc. Version-Release number of selected component (if applicable): glibc-2.17-20.fc19.x86_64 How reproducible: Always Steps to Reproduce: 1. $ download the attached reproducer 2. $ cc -xc -o dst dst.c 3. $ ./dst Actual results: === tz[0]: GMT, tz[1]: GMT timezone: 0, daylight: 0 call tzset() tz[0]: IST, tz[1]: IST timezone: -5:30, daylight: 0 === Expected results: === tz[0]: GMT, tz[1]: timezone: 0, daylight: 0 call tzset() tz[0]: IST, tz[1]: timezone: -5:30, daylight: 0 === Additional info: [1] https://www.gnu.org/software/libc/manual/html_node/Time-Zone-Functions.html#index-tzname-2716
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
IST used Daylight Saving Time during World War II, and this is reflected in tzdata. This means the reproducer is not a counterexample to the specification you quoted. *** This bug has been marked as a duplicate of bug 1077377 ***