It looks like this response has slipped under my radar. Sorry. On Sun, Aug 8, 2010 at 4:37 AM, Lennart Regebro <regebro at 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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4