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