[python-win32] how to best use datetime objects in pywin32?

Jason R. Coombs jaraco at jaraco.com
Tue Jan 13 19:57:49 CET 2009

Thanks for the words of encouragement.

> -----Original Message-----
> From: Vernon Cole [mailto:vernondcole at 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()
>>> timezone.utcnow()

Both of which call the respective functions in datetime.datetime and attach
the appropriate timezone?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6998 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-win32/attachments/20090113/604d2527/attachment.bin>

More information about the python-win32 mailing list