[Anders J. Munch] > If ctime/mtime/atime were to return datetime objects, that would > pretty much have to be UTC to not lose information in the DST > transition. I doubt that's what Walter wanted though, as that would > leave users with the job of converting from UTC datetime to local > datetime; - unless perhaps I've overlooked a convenient UTC->local > conversion method? To be honest, I'm not sure what the point would be of returning datetime objects for this use case. A time.time()-like value seems just fine to me. The quest for a single representation of time (as expressed by Walter's "We should have one uniform way of representing time in Python") is IMO a mistake; there are too many different use cases. Note that datetime intentionally doesn't handle things like leap seconds and alternate calendars. Those things are very specialized applications and deserve to be handled by application-specific code. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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