> >> I am not the maintainer of the datetime module, but based purely on what > >> you have said, I would consider that a bug. > > I don't. Do you really want every time function slowed by > re-initializing the timezone?
It depends; do you know what re-initializing entails and how costly that would be? I don't. The way I was thinking of it is, if the documentation for datetime.datetime.now() is (to begin), "Return the current local date and time." ...then, at least in the cases in which one changes one's system timezone during a running Python instance*, the docs are just not accurate for this method. (*which is not such a corner case given laptops that travel with us across them--often this timezone crossing is fundamental to one's work with that laptop) > I do believe that time.tzget can now be make to work now on Windows, and > that would be a proper tracker issue. Can you elaborate on how this would help my case? > > (Now change time zone to UTC, for example. Now clock reads 6:41pm.) > >> import datetime > > Without a restart, this is a no=op. Whoops, thanks; I just copied and pasted it twice. > As I said on the issue, passing a tz arg to now() will give the answer > for any timezone on earth. A user-friendly app displaying times should > let users choose. Are you saying that the app should require that the user enter their current time zone into the whenever they change time zones (in addition to their changing it in the Windows system clock)? And then using that tz in every call to datetime.datetime.now()? Thanks. -- http://mail.python.org/mailman/listinfo/python-list
