Paul Boddie <p...@boddie.org.uk> added the comment: 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: http://mail.python.org/pipermail/python-dev/2010-February/097710.html) - 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1667546> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
