It looks like this response has slipped under my radar. Sorry. On Sun, Aug 8, 2010 at 4:37 AM, Lennart Regebro <rege...@gmail.com> wrote: [skipped description of two alternative solutions] .. > For all of the reasons you give above, I think it's a bad idea. :-) > I did not give any reason for not having access to the information that is readily available through reasonably cross-platform C API. Can you elaborate on what you think is a bad idea?
> You need a proper time zone database to solve these issues, like pytz. Pytz is more ambitious than what I propose. I don't propose adding a timezone database to python or even a functionality to access system timezone database. All I want to add is a method to get aware local time in the system timezone. > Which incidentally solves the ambiguity problem as well. so the > solution is pytz. :-) No, it does not. In order to resolve the ambiguity, pytz adds a non-standard argument to tzinfo methods, but datetime objects don't know how to pass this argument and don't have data to determine its value to begin with. > What pytz doesn't have (but dateutil.tz does) is a timezone object > that uses the operating systems local timezone data, like > /etc/localzone on unix. That could be interesting to include, > possibly. Having a fixed time zone offset object for the localtime > seems a bad idea. The problem it solves is easy to get around, but the > problems created are not. This sounds like an argument against my "second alternative." As I explained, my preference is the same. Do you have an opinion on the localtime([t]) alternative? _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
