Thanks for the words of encouragement. > -----Original Message----- > From: Vernon Cole [mailto:vernondc...@gmail.com] > Sent: Tuesday, 13 January, 2009 12:19 > > Second, I am frustrated with the fact that Python's datetime > implementation is incomplete, since it lacks any standard way of > getting a time-zone-aware local time. It it truely mind boggling that > even datetime.datetime.utcnow() is time zone naive! If I specifically > ask for "utc" am I not specifying a time zone?! Mark said that "the > datetime module almost encourages timezone naïve objects." I would say > that it almost _forces_ it, since tzinfo objects are difficult to > construct. The only way I found to approximate my local timezone was > to go back to the old "time" module like "delta = > datetime.timedelta(seconds=time.timezone)".
The reason datetime doesn't provide timezone aware calls is because it explicitly refuses to provide a tz implementation. I was a little surprised by this decision at first, but I realized later why this was a good idea. Because there is no authoritative database of timezone data, they would be hard pressed to provide a "best of breed" solution for a default timezone implementation. By leaving the spec open, they left functionality lacking, but also drove others like us to implement various implementations with their various strengths and weaknesses. > > So, I am delighted that I am now able to say: > now = datetime.datetime.now(win32timezone.GetLocalTimeZone()) > [note: "tzinfo=" is superfluous] Please note that the current implementation of GetLocalTimeZone is fairly costly, parsing through the entire registry of time zones to find the correct one. A future implementation will drastically limit this cost. > My suggestion is this: > Let's make a module with a non-Windows-specific name (and provide for > a posix version of it also) so that I can write system independent > code. I've heard this request before, but the library is build on the assumption that the win32apis are available. I would say it's out of scope for this library to determine the local time zone for other platforms. That said, I find cross-platform compatibility very attractive. I did some looking into it, and I think the problem would be quite challenging. That is, the logic for getting the local time on Linux is different from Mac, and both are quite different from Windows. Separate libraries would be necessary to handle the various cases. I'm happy to provide a compatible interface such that one could opt to use win32timezone if the OS is Windows and choose the compatible library otherwise, but I feel the effort to include Linux and Mac support would be as much effort as the original library. Still, I may consider it at some point. > Also, it would be nice if the name were not quite so verbose. In > my ideal world, little typing should be required to do common things. > I would like to see something like: > > >>>herenow = datetime.datetime.now(timezone.local) > >>>gmt = datetime.datetime.now(timezone.utc) I assume you meant "gmt = datetime.datetime.utcnow(timezone.utc)" What about instead >>> timezone.now() And >>> timezone.utcnow() Both of which call the respective functions in datetime.datetime and attach the appropriate timezone? Jason
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
