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 pboddie
Recipients belopolsky, georg.brandl, gvanrossum, nnorwitz, pboddie, pitrou, techtonik
Date 2010-06-05.18:52:07
SpamBayes Score 0.140009
Marked as misclassified No
Message-id <>
Speaking for myself, I'm not sure whether I'm really the person to push this further, at least, although others may see it as a worthy sprinting topic. In principle, adding the extra fields is the right thing to do, merely because it exposes things from "struct tm" which were missing and which influence the other functions depending on it.

The only things remaining are to make sure that existing code doesn't change its behaviour with these new fields, and that the new fields work together with the time functions as expected. Thus, testing is the most important thing now, I think.

For the bigger picture, which shouldn't be discussed here, Python's way of handling times and dates probably needs improvement - this has been discussed already (a reference for anyone not involved is Anatoly's initial message in one recent discussion: - and I think usage of pytz is a step in the right direction, although it does not eliminate the need to learn about time zones (UTC, CET...), time "regimes" (Europe/Oslo, America/New_York...), "floating" times, and zone transitions (and ambiguous times).

Extending Python library support is potentially a sprinting topic, but not really a topic for discussion around this patch.
Date User Action Args
2010-06-05 18:52:10pboddiesetrecipients: + pboddie, gvanrossum, nnorwitz, georg.brandl, belopolsky, pitrou, techtonik
2010-06-05 18:52:10pboddiesetmessageid: <>
2010-06-05 18:52:08pboddielinkissue1667546 messages
2010-06-05 18:52:07pboddiecreate