This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author belopolsky
Recipients belopolsky, lemburg, vstinner
Date 2016-09-12.21:31:58
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1473715918.32.0.513950864316.issue28108@psf.upfronthosting.co.za>
In-reply-to
Content
> I don't think tzname is really all that useful.

I agree. More so after issue 25283 (Make tm_gmtoff and tm_zone available on all platforms).  That's why I don't see why the time module need to set tzname to anything other than what the C library does.

Interestingly, glibc may even change tzname[0] as a side-effect of calling  localtime:

(on Linux)
$ cat lt.c
#include <time.h>
#include <stdio.h>


int main() {
  struct tm tm = {0, 0, 0, 1, 1, -100};
  time_t t;
  t = mktime(&tm);
  localtime(&t);
  printf("%s/%s  %d %d\n", tzname[0], tzname[1], timezone, daylight);
  t = 0;
  localtime(&t);
  printf("%s/%s  %d %d\n", tzname[0], tzname[1], timezone, daylight);
}

$ gcc lt.c -o lt
$ ./lt
LMT/EDT  18000 1
EST/EDT  18000 1

I think that's a bug in glibc because it makes no sense to change tzname[0] while not updating timezone.
History
Date User Action Args
2016-09-12 21:31:58belopolskysetrecipients: + belopolsky, lemburg, vstinner
2016-09-12 21:31:58belopolskysetmessageid: <1473715918.32.0.513950864316.issue28108@psf.upfronthosting.co.za>
2016-09-12 21:31:58belopolskylinkissue28108 messages
2016-09-12 21:31:58belopolskycreate