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

[Paul Moore]

2009/1/13 Mark Hammond <mhammond at skippinet.com.au>:
> So, my question is: Assuming we want to set a time object into a SYSTEMTIME
> or FILETIME structure, what should pywin32 do when faced with a timezone
> naïve object?  I see only 2 options:
>
> * Given the SYSTEMTIME assumes UTC and the object is timezone naïve, the
> code could fail, refusing the temptation to guess.
>
> * Assume that the user knows that they are doing, and just copy the time
> elements to the structures.  In effect, this would be assuming a timezone
> naïve object is already in UTC (FILETIMES again may be more complex - if the
> target was a FILETIME I think we would want to assume whatever timezone we
> *return* FILETIME objects in - which may be another argument for returning
> FILETIMEs in UTC)

Is there a reason you don't see assuming a timezone of
win32timezone.GetLocalTimeZone() as a reasonable option? It seems like
the right thing to do to me. (If the user is using timzone-naive
objects, they are probably naive about timezones, and hence likely to
be assuming that the "local" timezone applies). This can be as simple
as

    val = val.replace(tzinfo=win32timezone.GetLocalTimeZone())

I'm not keen on giving an error - your example of using SetTimes to
set one or more file times to now is a good example, as a user I'd
find an error both confusing and (once I understood it) somewhat
annoying (as I'd probably still forget every time!). On the other
hand, UTC seems a bad default - probably worse for people like me in
the UK, who would write programs that looked correct all winter, and
would then have to fix them all in March :-)

> The first seems more attractive (ie, the user may *not* know what they are
> doing, so forcing them to be explicit actually helps them), but may make
> life painful (and already is painful for the test suite).

If my 3rd option above isn't reasonable for some reason, I'd vote for
the first option, simply because the bugs caused by the second would
be so subtle and easily missed.

Paul.