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 gvanrossum
Recipients
Date 2007-03-02.15:48:49
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
Hm.... I'm not sure I understand why the first bit of code didn't work.  Can you give a concrete example?  (I.e. what was t, what was returned by localtime(t), and what were the three time variables that day.)

I don't know the details of Western Australia's DST change.  But looking at the source of timemodule.c, I notice that it simply samples the timezone on Jan 1st and July 1st, and if they differ, decides which one is summer time by which one is smaller.  Your remark that the problem righted itself in January makes me wonder -- between what dates did you have DST?

Alternatively, it could be that your system simply didn't have the correct DST change data loaded yet (this happens all the time when governments change the rules).  Can you rule that out?  I really don't want to have to change Python in order to correct for *that* problem.

Yet another question, if you were to code this in C, how would you write it?

Regardless, I think that it would be useful to support tm_gmtoff and other struct tm entries, the same way that we do this in struct stat.

You could probably also get the correct result (assuming your system's timezone database is correct) by comparing localtime() and gmtime().  But the reverse engineering is a bit painful; your trick using datetime essentially does that.
History
Date User Action Args
2007-08-23 14:51:37adminlinkissue1647654 messages
2007-08-23 14:51:37admincreate