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. > 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) _______________________________________________ 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
