Phillip J. Eby wrote:
> At 09:26 PM 6/26/2005 -0400, Bob Ippolito wrote:
>
>> On Jun 26, 2005, at 8:54 PM, Phillip J. Eby wrote:
>>
>>> At 12:22 AM 6/27/2005 +0200, Dörwald Walter wrote:
>>>
>>>> Phillip J. Eby wrote:
>>>>
>>>>> I'm also not keen on the fact that it makes certain things
>>>>> properties whose value can change over time; i.e. ctime/mtime/
>>>>> atime
>>>>> and
>>>>> size really shouldn't be properties, but rather methods.
>>>>
>>>> I think ctime, mtime and atime should be (or return)
>>>> datetime.datetime objects instead of integer timestamps.
>>>
>>> With what timezone? I don't think that can be done portably and
>>> unambiguously, so I'm -1 on that.
>>
>> That makes no sense, timestamps aren't any better,
>
> Sure they are, if what you want is a timestamp. In any case, the
> most common use case I've seen for mtime and friends is just
> comparing against a previous value, or the value on another file,
> so it doesn't actually matter most of the time what the type of the
> value is.
I find timestamp values to be somewhat opaque. So all things being
equal, I'd prefer datetime objects.
>> and datetime
>> objects have no time zone set by default anyway.
>> datetime.fromtimestamp(time.time()) gives you the same thing as
>> datetime.now().
>>
>
> In which case, it's also easy enough to get a datetime if you
> really want one. I personally would rather do that than complicate
> the use cases where a datetime isn't really needed. (i.e. most of
> the time, at least in my experience)
We should have one uniform way of representing time in Python. IMHO
datetime objects are the natural choice.
Bye,
Walter Dörwald
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
