On Fri, 3 Feb 2012 11:04:14 -0800 Jeffrey Yasskin <jyasskin at gmail.com> wrote: > On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > > datetime.datetime > > > > - real problem with the idea is that not all timestamps can be easily > > made absolute (e.g. some APIs may return "time since system started" > > or "time since process started") > > I think this is an argument for returning the appropriate one of > datetime or timedelta from all of these functions: users need to keep > track of whether they've got an absolute time, or an offset from an > unspecified starting point, and that's a type-like distinction. Keep in mind timedelta has a microsecond resolution. The use cases meant for the PEP imply nanosecond resolution (POSIX' clock_gettime(), for example). > A plain number of seconds is superficially simpler, but it forces more > complexity onto the user, who has to track what that number > represents. If all you are doing is comparing timestamps (which I guess is most of what people do with e.g. st_mtime), a number is fine. If you want the current time and date in a high-level form, you can already use datetime.now() or datetime.utcnow() (which "only" has microsecond resolution as well :-)). We don't need another way to spell it. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4