It looks like this response has slipped under my radar. Sorry. On Sun, Aug 8, 2010 at 4:37 AM, Lennart Regebro <regebro@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?