Great work, Jason!
Maybe this would be a good time for a feature request. I am a fanatic
about operating system independent code, which is weird because all of
my open source code contributions are Windows specific. Go figure.
First, let me say that I like Paul's third option the best. When I am
using time in a "casual" manner, my mental framework is always local.
If the time says "noon" I would expect to look out the window and find
that the sun was somewhere near the middle of the sky. Similarly, I
would expect my naive file times to be in local terms.
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)".
So, I am delighted that I am now able to say:
now = datetime.datetime.now(win32timezone.GetLocalTimeZone())
[note: "tzinfo=" is superfluous]
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. 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)
so, using Paul's suggestion:
>>>now = datetime.datetime.now()
>>>win32api.SetFileTimes("foo", now, now, now)
and:
>>>.win32api.SetFileTimes("foo", herenow, herenow, herenow)
and:
>>>win32api.SetFileTimes("foo", gmt, gmt, gmt)
would give the (approximately) same result.
--
Vernon Cole
On Tue, Jan 13, 2009 at 2:37 AM, Paul Moore <p.f.mo...@gmail.com> wrote:
> 2009/1/13 Mark Hammond <mhamm...@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.
> _______________________________________________
> python-win32 mailing list
> python-win32@python.org
> http://mail.python.org/mailman/listinfo/python-win32
>
_______________________________________________
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
